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ABSTRACT 


The  puipose  of  this  thesis  is  to  design  a  type  checker  for  the  SPEC  language  and  to 
investigate  its  implementation  using  an  attribute  grammar  tool.  SPEC  is  a  formal 
language  for  writing  black-box  specifications  for  large  software  systems.  The  type 
checker  is  a  software  tool  which  verifies  the  semantic  accuracy  of  the  declarations  and 
their  uses  in  a  SPEC  source  program.  The  design  specifically  addresses  language 
features  which  are  especially  important  for  large  software  system  specification  such  as 
generic  parameters,  name  and  operator  overloading,  subtypes,  importation  and 
inheritance.  Additional  discussion  is  provided  concerning  the  handling  of  the  "non-block 
structured"  nature  of  the  specification  language.  This  thesis  implements  two  of  the  three 
aspects  of  type  checking-name  analysis  and  error  reporting.  Additionally,  a  definitive 
framework  is  laid  for  the  final  aspect,  type  consistency  analysis. 
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IX 


L  INTRODUCTION. 


The  field  of  Software  Engineering  is  a  growing  area  of  interest  in  computer  science. 

¥  Many  systems  are  currently  being  developed,  using  various  methodologies,  to  support 

large  scale  software  development.  One  of  these  systems  uses  the  functional  specification 
language  SPEC  to  define  the  syntax  and  semantics  of  these  projects.  SPEC  is  a  language, 
developed  by  Berzins  [Ref.  1],  for  writing  black-box  specifications  for  the  components  of 
the  software  system  in  the  functional  specification  stage  of  software  development.  To 
increase  the  reliability  of  this  code  a  type  checking  tool  has  been  developed  to 
semantically  validate  the  various  type  declarations  used  in  the  specification.  This  thesis 
describes  the  methodology  used  and  the  actual  implementation  of  this  type  checker. 

A.  OBJECTIVES. 

-  The  primary  objective  of  this  thesis  is  to  design  and  implement  a  language  dependent 

type  checker  for  the  specification  language  SPEC.  Appendix  A  and  [Ref.  1]  contain  a 
listing  of  the  grammar  for  the  SPEC  language.  The  code  for  the  type  checker  is  written 
entirely  as  an  attribute  grammar.  This  code  is  then  compiled  using  the  Kodiyak 
Application  Generator,  producing  executable  code. 

It  is  also  desired  that  the  type  checker  be  easily  modifiable  in  the  event  that 
extensions  are  incorporated  into  the  SPEC  language.  By  using  an  attribute  grammar  to 

\.  specify  the  program  and  an  application  generator  to  generate  the  code,  the  program  can 
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be  modified  with  relative  ease.  The  efficiency  of  the  code  is  not  a  limiting  factor, 
because  optimizations  may  be  coded  at  a  later  date. 

The  final  objective  is  to  abstract  the  process  used  to  develop  the  type  checker  and 
develop  an  algorithm  for  producing  type  checkers  for  other  specification  languages.  This 
algorithm  will  be  a  direct  result  of  the  insight  gained  from  the  design  and  implementation 
of  the  SPEC  language  tool. 

B.  RESEARCH  QUESTIONS. 

There  are  two  pertinent  research  questions  for  this  thesis.  First,  and  foremost,  what 
are  the  underlying  issues  in  the  design  and  implementation  of  a  type  checker  for  a 
specification  language  using  an  application  generator?  What  is  the  impact  of  these  issues 
on  portability,  readability,  modifiability  and  efficiency  of  the  code? 

Finally,  how  would  this  type  checker  be  best  integrated  into  a  programming 
environment?  What  facilities  must  this  programming  environment  provide?  Should  the 
type  checker  be  optimized  to  provide  better  execution  speed? 

C.  THE  HISTORY  AND  SUCCESSFUL  APPLICATIONS  OF  ATTRIBUTE 

GRAMMARS  TO  SIMILAR  PROBLEMS. 

Attribute  grammars  are  frequently  used  for  specifying  the  semantic  meaning  of 
source  programming  languages.  Additionally,  with  the  aid  of  application  generators, 
these  grammars  have  been  used  to  generate  compilers  and  other  tools  for  the  recognition 
and  transformation  of  programs  coded  in  these  source  languages. 
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1.  The  Context  Free  Nature  of  SPEC—A  Pretty  Printer. 

All  language  grammars  are  classified  by  the  complexity  of  the  productions  that 
produce  that  language.  The  Chomsky  Heirarchy,  named  after  Noam  Chomsky,  divides 
languages  into  four  classes-type  0  (unrestricted)  grammars,  type  1  (context  sensitive) 
grammars,  type  2  (context  free)  grammars  and  type  3  (regular)  grammars.  Type  0 
grammars  contain  the  set  of  all  languages,  type  1  contains  a  subset  of  that,  etc.  Of  these 
four  classes,  type  3  (context  free)  and  type  4  (regular)  are  of  the  most  interest  in 
programming  language  design  because  they  can  be  used  to  describe  the  structure  and 
basic  symbols  of  a  program.  Most  standard  computer  languages  in  use  today  can  be 
described  with  a  context  free  grammar  since  efficient  parsing  algorithms  are  known  for 
this  class  of  languages.  The  SPEC  specification  language  is  described  using  a  context 
free  grammar. 

A  thesis  recently  completed  at  the  Naval  Postgraduate  School  [Ref.  2]  developed 
a  program  using  the  Kodiyak  application  generator  and  an  attribute  grammar  to  print 
SPEC  specifications  in  a  properly  formatted  /  indented  manner.  The  Kodiyak  application 
generator  is  a  tool  for  converting  context  free  attribute  grammars  into  an  executable 
program.  This  "Pretty  Printer"  program  demonstrated  that  SPEC  is  indeed  context  free 
because  the  Kodiyak  tool  could  convert  the  attribute  grammar  representation  into 
executable  code  which  formats  SPEC  specifications.  The  thesis  also  demonstrated  that 
attribute  grammars  are  ■*  feasible  way  to  create  tools  for  the  SPEC  language. 


3 


2.  MSG.84  and  MSG.85--A  Translator  for  a  Specification  Language. 

MSG. 84  and  MSG  85  are  specification  languages  developed  at  the  University  of 
Minnesota.  They  have  been  used  extensively  in  software  engineering  classes  for 
specifying  software  systems.  In  the  Spring  of  1984,  a  translator  was  written  to  translate 
these  specifications  into  the  Lisp-like  DBL  [Ref.  3]  assertions.  This  translator,  from 
which  the  Kodiyak  application  generator  evolved,  revealed  some  design  flaws  in  the 
MSG  language.  These  flaws  were  corrected  and  a  translator  now  exists  for  the 
conversions.  Additionally,  a  reverse  translator  was  written  to  convert  the  DBL  assertions 
produced  into  MSG.  This  process  of  translation  and  reverse  translation  insured  that  the 
translation  to  DBL  was  "lossless"  and  that  the  semantic  meaning  of  all  the  MSG 
constructs  was  preserved. 

3.  The  Design  of  a  Compiler-Farrow  1984. 

Attribute  Grammars  have  long  been  championed  as  a  promising  basis  for 
compiler  writing  systems.  Many  different  compiler-compilers  such  as  Yacc  [Ref.  4], 
Linguist  [Ref.  5]  and  Kodiyak  [Ref.  6]  have  been  developed.  One  of  the  major 
drawbacks  however,  has  been  the  inability  of  these  compilers  to  compete  in  the 
commercial  market  with  those  compilers  produced  by  other  means  due  to  their  memory 
requirements  and  speed.  The  Pascal-86  compiler  developed  by  Intel  Corporation  is  based 
on  an  attribute  grammar  and  application  generator.  It  was  successfully  marketed  as  a 
production  compiler  and  was  developed  in  a  two  stage  process.  The  first  phase  was 
developed  using  the  Linguist-86  application  generator  and  performed  semantic  analysis, 
storage  allocation  and  translation  to  intermediate  code.  The  second  part  of  the  compiler 
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takes  the  intermediate  code  produced  by  the  semanticist  unit  and  generated  8086 
microprocessor  object  code.  The  compiler  has  been  marketed  succesfully  and  it  was 
noted  that  the  development  process  was  significantly  enhanced  due  to  the  use  of  an 
attribute  grammar. 

4.  Syn— A  Graphical  Representation  of  Bachus  Naur  Form. 

Syn  is  a  translator  developed  with  the  Kodiyak  application  generator  that 
translates  a  grammar  expressed  in  the  Bachus  Naur  Form  into  directives  in  the  PIC 
graphics  language.  The  translator  required  approximately  two  man-weeks  of  work  to 
implement  by  a  user  initially  unfamiliar  with  the  Kodiyak  application  generator  [Ref.  6]. 
The  significant  time  savings  realized  by  the  use  of  an  application  generator  in  the 
development  of  this  tool  reaffirms  that  application  generators  are  an  effective  tool  for 
developing  large  applications. 

5.  The  Chameleon  Architecture. 

The  Chameleon  project  [Ref.  7]  is  an  ongoing  project  at  Ohio  State  University 
that  is  developing  an  architecture  to  support  the  specification,  construction  and  use  of 
data  translation  tools.  The  architecture’s  primary  tool  is  an  application  generator  that  will 
take  attribute  grammar  specifications  and  produce  the  tools  needed  to  translate  the  data. 
An  application  generator  was  choosen  as  the  primary  tool  in  this  architecture  due  to  the 
readability  and  ease  of  understanding  of  the  attribute  grammar  specifications. 
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D.  A  SPECIFICATION  TYPE  CHECKER  AND  "CASE". 

1.  Description  of  CASE. 

CASE  is  an  acronym  for  Computer  Aided  Software  Engineering,  an  area  of 
ongoing  research  at  the  Naval  Postgraduate  School.  Some  of  the  projects  currently  being 
developed  in  this  area  include  a  Software  Rapid  Prototyping  System,  Syntax-directed 
editors  for  SPEC  and  formatters  for  the  SPEC  language.  Eventually,  all  of  these  tools 
will  be  integrated  into  an  environment  to  aid  the  software  engineering  process  and 
specifically  ADA  program  development.  It  is  also  anticipated  that  this  type  checker  and 
its  principles  will  be  integrated  with  a  syntax  directed  editor  to  build  a  superior  editing, 
type  checking  tool. 

2.  Benefits  for  CASE. 

A  type  checker  would  be  an  extremely  valuable  addition  to  any  CASE 
environment.  Since  it  has  been  proven  that  many  design  errors  manifest  themselves  as  a 
type  inconsistency,  the  type  checker  would  assist  in  the  identification  of  errors  that  could 
defeat  the  reliability  of  the  specification. 
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H.  BACKGROUND. 


A.  TYPE  CHECKER. 

1.  Definition. 

A  Type  Checker  is  a  tool  used  to  validate  the  semantic  accuracy  of  the  uses  and 
declarations  of  name  structures  in  a  program.  There  are  two  types  of  type  checkers 
currently  in  use  today.  The  kind  of  type  checker  used  for  a  language  is  often  dependent 
on  the  features  of  that  language.  The  first  kind,  a  dynamic  type  checker,  executes 
concurrently  with  the  program  and  checks  the  validity  of  dynamically  declared  variables 
as  they  are  encountered.  Since  this  tool  runs  as  part  of  the  executable  program,  the 
program  performance  is  degraded  and  errors  are  reported  during  run  time  instead  of 
before  the  compile  -  link  cycle. 

The  second  kind  of  type  checker  is  a  static  type  checker.  This  tool  takes  as  input 
a  file  or  multiple  files  containing  the  source  program  /  specification  and  provides  the  user 
with  a  report  detailing  any  type  inconsistencies  that  were  discovered.  It  can  be  run  before 
a  program  is  compiled  and  reports  inconsistencies  so  that  they  may  be  corrected  before 
the  compile  -  link  cycle. 

The  process  of  validating  the  semantic  accuracy  of  the  structures  in  a  program  is  a 
multi-part  process.  The  first  part,  called  name  analysis,  entails  finding  the  definition  of 
that  name  applicable  to  each  use  of  the  name.  If  there  has  been  no  definition  of  that 
name,  the  type  checker  will  either  make  a  definition  based  on  the  name’s  use  or  report  an 
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error.  The  other  two  phases  deal  with  obtaining  the  operator  being  used  and  confirming 
that  the  results  of  the  name  analysis  are  indeed  allowable  with  the  given  operator. 
Additionally,  a  type  checker  must  consider  various  language  features  such  as  operator 
overloading,  name  scoping  and  the  binding  method  used. 

2.  Scope  Considerations. 

The  scope  of  a  name  is  the  portion  of  the  program  over  which  it  may  be  used 
[Ref.  8].  Many  languages,  called  block  structured  languages,  allow  the  nesting  of  various 
names  within  themselves.  The  most  recent  occurence  defining  the  currently  available 
definition  of  that  name.  Another  constraint  imposed  by  scope  is  whether  or  not  a  variable 
is  visible  inside  of  the  structures  that  are  declared  inside  of  it.  Both  of  these  constraints 
and  others  must  be  considered  in  the  design  of  the  type  checker. 

B.  ATTRIBUTE  GRAMMARS. 

1.  Attribute  Grammars. 

Attribute  grammars  were  introduced  by  Knuth  [Ref.  9]  and  advocated  as  a  means 
of  translating  grammar  specifications  into  executable  code.  They  have  been  used 
repeatedly  to  develop  compilers,  compiler-compilers  (application  generators)  and  other 
useful  tools.  One  of  the  most  significant  features  of  attribute  grammars  is  their 
readability.  Attribute  grammars  are  very  similar  to  the  Bachus-Naur  form  (BNF)  of 
representing  the  syntactic  structure  of  a  program  and  tends  to  be  self-documenting  since 
they  represent  a  relation  between  the  syntax  and  semantics  of  the  language. 
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a.  Definition. 

An  attribute  grammar  is  based  upon  a  context-free  grammar  G  =  (N,  T,  P,  Z) 
and  associates  a  set  A(X)  of  attributes  with  each  symbol,  X,  in  the  grammar  G.  The 
context-free  grammar  is  used  to  represent  the  syntactic  structure  of  the  language  while 
the  attributes  are  used  to  represent  context-sensitive  (semantic)  properties  of  the 
language. 

b.  Synthesized  and  Inherited  Attributes. 

The  attributes  of  an  attribute  grammar  may  be  divided  into  two  classes.  The 
first  of  these,  synthesized  attributes,  are  those  attributes  of  symbols  on  the  Left  hand  side 
of  a  production  that  are  derived  from  the  return  value  of  the  elements  on  the  right-hand 
side  of  the  production.  Conversely,  inherited  attributes  are  those  attributes  of  symbols 
on  the  right  hand  side  whose  values  are  derived  from  the  values  of  the  attributes  of  the 
symbols  on  the  left  hand  side. 

c.  Semantic  Functions. 

Each  rule  in  an  attribute  grammar  has  semantic  functions  associated  with  it 
that  define  the  values  of  some  attributes  in  the  production  in  terms  of  other  attributes  in 
the  function.  These  functions  resolve  the  actions  that  the  application  generator  takes 
upon  recognizing  the  production  associated  with  them  and  define  the  values  of  all 
inherited  and  synthesized  attributes. 

2.  Automatic  Parsing  of  Attribute  Grammars-Application  Generators. 

Application  generators  have  many  different  uses.  They  have  been  used  frequently 
for  the  implementation  of  compilers,  the  verification  of  the  context  sensitive  constraints 
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on  languages  and  are  becoming  popular  for  the  design  and  implementation  of  various 
other  tools.  One  of  their  most  significant  advantages  is  that  they  let  the  user  customize 
and  reuse  a  general  software  design  easily. 
a.  Definition  and  Overview. 

Application  generators  are  tools  that  produce  executable  code  from  a  grammar 
specification.  The  executable  program  produced  will  model  the  semantic  meaning  of  the 
grammar  specification  precisely.  The  application  generator  consists  of  two  parts,  a 
variant  part  and  an  invariant  part.  The  invariant  part  consists  of  fixed  assumptions  about 
the  domain  or  implementation  such  as  the  source  language.  The  variant  part  of  the 
application  generator  corresponds  to  the  attribute  grammar  specification  of  the  system 
that  is  to  be  produced. 

The  process  of  using  the  application  generator  begins  with  the  attribute 
grammar  specification.  This  specification  is  generally  simpler,  in  both  syntax  and 
semantics  than  the  programming  language  it  specifies.  Acting  much  like  a  language 
compiler,  the  application  generator  takes  this  specification  and  produces  code  in  some 
invariant  language  (e.g.,  "C")  which  is  then  compiled  with  a  standard  compiler  to 
produce  the  executable  application.  An  end-user  may  then  take  this  executable 
application  and  provide  it  with  input  from  which  the  application  will  produce  whatever 
the  original  specification  specified. 

There  are  many  different  considerations  in  the  choice  of  an  application 
generator  for  a  specific  task.  The  first  and  foremost  of  these  is  if  the  application 
generator  can  perform  the  task  desired.  Other  considereations  include  what  built-in  types 
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and  operators  are  available  in  the  applications  generator,  the  readability  of  the 
specification  language  (attribute  grammar)  used  by  the  tool,  the  availability  of  the 
generator  itself  and  the  attribute  evaluation  method. 

b.  The  Semantic  Tree. 

The  basic  principle  of  operation  behind  an  application  generator  and  its 
associated  attribute  grammar  is  that  any  program  can  be  represented  by  a  semantic  tree. 
This  tree  will  contain  nodes,  the  interior  ones  representing  productions  and  the  leaves 
representing  terminal  symbols  in  the  target  language.  Associated  with  each  node  is  it’s 
attributes. 

c.  Semantic  Analysis. 

The  process  of  evaluating  each  node  in  the  semantic  tree  is  called  semantic 
analysis.  As  the  attributes  of  each  node  are  evaluated,  the  semantic  functions  are 
executed  and  any  side-effects  associated  with  them  are  performed.  Different  algorithms 
have  been  derived  for  resolving  the  attributes  in  the  semantic  tree  and  most  of  them  have 
been  implemented  in  at  least  one  application  generator.  The  choice  of  the  algorithm 
depends  on  the  properties  of  the  attribute  grammar  and  the  qualities  desired  in  the 
resultant  product  [Ref.  6].  To  ensure  that  the  translator  produced  by  the  application 
generator  performs  exactly  as  desired,  it  is  imperative  that  the  method  used  to  evaluate 
the  attributes  be  understood. 

d.  Advantages  and  Disadvantages. 

Application  generators  produce  tools  that  are  more  reliable  than  a  conventially 
coded  tool  because  of  their  very  nature.  Since  it  accepts  a  specification  of  the  tool  to  be 


produced  and  uses  well-known  techniques,  it  is  less  likely  to  accept  syntactically 
incorrect  input  and  generate  unexpected  output  or  terminate  abnormally  [Ref.  6].  Since 
there  is  a  close  link  between  the  syntax  and  semantics  of  the  specification,  the  volume  of 
code  required  is  reduced  and  it  is  more  repairable.  The  application  generator  tends  to  be 
self-documenting  because  its  source  code  allows  users  to  quickly  determine  the  syntactic 
requirements  of  programs.  If  an  application  generator  is  constructed  properly  it  can  be 
very  portable.  Typically  it  can  be  written  in  its  own  language  and  it  produces  an 
appropriate,  portable  target  language,  the  application  generator  can  be  transfered  to  other 
computers  with  relative  ease. 

The  most  important  advantage  of  an  application  generator  is  its  ability  to  cut 
down  on  the  time  and  cost  to  build  a  tool  with  it.  Since  a  programmer’s  productivity  is 
largely  constant  in  the  number  of  lines  of  code  produced  per  unit  time  [Ref.  10],  a  tool 
that  generates  a  program  equivalent  to  a  high  level  language  program  with  less  actual 
lines  of  code  will  increase  productivity.  Additionally,  since  there  is  generally  a  close 
correlation  between  the  Bachus-Naur  representation  of  the  grammar  and  the  specification 
input  to  the  application  generator,  the  time  involved  in  the  development  of  the  program  is 
decreased  as  it  is  with  most  fourth  generation  languages  [Ref.  1 1]. 

A  major  drawback  of  application  generators  is  that  since  they  are  table  driven, 
they  tend  to  produce  executable  code  that  is  not  as  efficient  as  equivalent  "hard-coded" 
tools.  Additionally,  since  the  value  of  the  attributes  used  must  be  copied  between 
attributes  so  that  these  values  may  reach  the  root  to  be  output,  bulk  is  added  to  the 
program’s  specification.  Both  of  these  problems  are  currently  being  researched.  Some 
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solutions  have  been  put  forth.  To  reduce  the  number  of  copy  rules  (and  thus  increase 
readability),  a  macro  preprocessor  may  be  used.  Additionally,  research  has  proven  that 
hard-coding  the  tables  used  during  the  evaluation  process  tends  to  produce  a  speedup 
factor  of  6-10%  [Ref.  12]. 

e.  Existing  Application  Generators. 

Many  different  application  generators  have  been  developed.  Some  of  the 
most  popular  include  the  HLP  (Helsinki  Language  Processor)  system  [Ref.  13],  Delta 
[Ref.  14],  Mug2  [Ref.  15],  Aparse  [Ref.  16]  Gag  [Ref.  17],  YACC  [Ref.  4],  Linguist-86 
[Ref.  5]  and  Kodiyak  [Ref.  6].  Each  uses  a  different  algorithm  for  evaluating  the 
attributes  of  the  semantic  tree  and  accepts  different  classes  of  attribute  grammars. 

C.  THE  KODIYAK  APPLICATION  GENERATOR. 

The  Kodiyak  application  generator  was  developed  at  the  University  of  Minnesota  and 
is  intended  for  building  prototype  languages  and  translators.  The  specification  describes 
all  aspects  of  translation:  input  scanning,  parsing,  semantic  processing  and  output.  It  has 
been  used  to  build  translators  for  other  specification  languages,  text  processing  tools, 
database  query  languages  and  a  pretty  printer  for  the  SPEC  language. 

1.  Justification  for  use. 

Kodiyak  is  an  exceptional  language  translator  that  integrates  the  functions  of  the 
YACC  [Ref.  4]  parser  generator  and  LEX  [Ref.  18]  scanner  generator  into  a 
comprehensive  whole,  hiding  the  procedural  and  interface  details  of  these  tools.  Its 
compact  attribute  grammar  specification  describes  every  aspect  of  the  translation  process, 
produces  portable  "C"  language  code  and  then  compiles  that  into  executable  code. 


Additionally,  Kodiyak  can  process  it’s  input  through  a  macro-preprocessor  allowing 
repetitive  code  to  be  replaced  by  a  single  statement  thus  improving  a  programs’ 
readability.  Kodiyak  allows  evaluation  of  the  largest  class  of  attribute  grammars  and 
contains  built-in  types  capable  of  specifying  symbol  tables.  Its  many  features, 
capabilities,  portability,  and  availability  make  it  an  ideal  tool  for  the  implementation  of 
this  thesis. 

2.  A  General  Description  of  the  Kodiyak  Language. 

All  of  the  points  covered  in  the  following  section  come  directly  from  Appendix  A 
of  Herndon  [Ref.  6]  Kodiyak  Program  Layout.  It  is  intended  to  describe  the  operation  of 
the  Kodiyak  translator  in  sufficient  detail  to  facilitate  understanding  of  the  type  checker 
code.  It  is  not  intended  to  be  a  detailed  reference.  If  further  or  more  detailed  information 
is  needed  it  is  recommended  that  Herndons’  doctoral  dissertation  [Ref.  6]  be  consulted. 
a .  Format. 

Eveiy  Kodiyak  program  has  three  sections.  The  first  section  describes  the 
features  of  the  lexical  scanner  that  is  to  be  used  to  translate  the  source  text  into  tokens 
and  operator  precedences  and  associativities  for  those  tokens.  The  second  section 
declares  the  names  and  types  of  the  attributes  associated  with  each  grammar  symbol. 
The  third  section  contains  the  grammar  and  attribute  equations  that  define  the  translation. 
These  sections  are  separated  by  a  double  percent  symbol  ("%%")  on  a  line  by  itself. 
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b.  Comments. 


There  are  two  forms  of  comments  in  Kodiyak.  The  first  is  the  C  and  PL/I 
style  comment  delimined  by  "/*"  and  The  second  is  introduced  by  an  exclamation 
point "!"  and  continues  to  the  end  of  the  line. 
c.  Lexical  Scanner  Section. 

Each  statement  in  the  lexical  section  of  a  Kodiyak  program  describes  the 
terminal  symbols  of  the  translation  in  some  way.  The  primary  function  of  statements  in 
this  section  is  to  specify  the  terminal  symbols  of  the  grammar,  and  how  input  text  is  to  be 
transformed  into  these  symbols.  The  secondary  function  of  this  section  is  to  specify  a  set 
of  operator  precedences  to  be  used  with  the  grammar. 

The  transformation  of  input  text  to  terminal  symbols  is  denoted  by  a  regular 
expression.  Figure  2. 1  shows  examples  of  lexical  definitions.  These  definitions  are  an 
excellent  sampling  of  the  typical  definitions.  The  first  definition  demonstrates  the 
general  format  of  a  lexical  definition.  The  second  definition  demonstrates  how  a  specific 
string  can  be  recognized  and  the  third  definition  shows  how  a  changeable  string  of  text, 
such  as  a  variable  name,  may  be  recognized.  The  rules  are  examined  in  the  way  they  are 
listed,  thus  implying  precedence.  The  first  rule  that  is  recognized  will  determine  the 
terminal  symbol  (token)  that  will  be  returned. 
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TERMINAL_NAME  :  REGULAR_EXPRESSION 
!  Formal  for  a  lexical  definition. 

!  A  Terminal_name  is  specified  by  the  Regular_expression. 


BEGIN  .  "BEGIN"  I  "begin" 

!  The  terminal  symbol  BEGIN  is  recognized  if  either  "BEGIN"  or 
!  "begin"  is  scanned  from  the  input. 


ID  :[A-Za-z][A-Za-zO-9]* 

!  The  terminal  symbol  ID  is  recognized  if  a  string  starting  with 
!  an  alphabetic  character  followed  by  zero  or  more  alphanumeric 
!  characters  is  scanned  from  the  input. 


Figure  2.1 

Sample  Lexical  Definitions. 


Operator  characters  are  an  extremely  important  part  of  any  regular  expression. 
They  allow  ways  for  specifying  choices,  repeating  characters  and  ranges  of  characters. 
All  valid  operator  characters  used  in  Kodiyak  regular  expressions  are  enumerated  in 
Figure  2.2.  If  you  desire  additional  information  on  construction  of  regular  expressions 
and  further  examples,  the  original  Lex  documentation  [Ref.  18]  provides  an  authoritive 
source. 


16 


Operator  Svmbol 

Meanine 

Delimiter  between  Token  name  and  regular  expression. 

\ 

By  preceding  an  operator  character  with  the  backslash,  the 
operator  will  be  recognized  as  a  text  character. 

n 

Whatever  is  contained  between  a  pair  of  quotes  is  text  characters. 

[] 

Indicates  a  character  class.  Any  character  between  the  brackets 
will  be  recognized.  The  only  operator  symbols  having  meaning 
between  brackets  are "V  and  "A". 

A 

If  the  Caret  Symbol  appears  outside  of  a  set  of  brackets,  the 
string  following  it  must  appear  at  the  beginning  of  a  line 
to  be  matched.  If  it  appears  as  the  first  character  after  a 
left  bracket,  it  indicates  that  the  resulting  string  is  to  be 
complemented,  (i.e.  [Aabc]  matches  everything  except  a,b  or  c. 

+ 

Symbolizes  an  expression  that  is  to  be  repeated  one  or  more  times. 

* 

Symbolizes  an  expression  that  is  to  be  repeated  zero  or  more  times. 

l 

Indicates  alternation.  It  may  be  interpreted  verbally  as  an  "or". 

0 

Parenthesis  are  used  for  grouping. 

s 

If  the  very  last  character  of  a  regular  expression  is  the  dollar 
sign,  the  expression  will  only  be  matched  at  the  end  of  a  line. 

/ 

The  forward  slash  between  two  regular  expressions  means  that  the 
terminal  symbol  is  only  matched  if  the  first  regular  expression 
is  immediately  followed  by  the  second  regular  expression. 

7 

The  question  mark  precedes  an  optional  part  of  an  expression. 

- 

The  dash  operator  specifies  ranges. 

The  period  operator  matches  any  character. 

n 

Curly  Braces  specify  either  repetition  or  definition  expansion. 

Figure  2.2 

Lexical  Section  Operators. 
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Kodiyak  also  provides  ways  to  increase  the  readability  of  regular  expressions. 
By  defining  the  basic  lexical  classes  (digits,  alphabetics,  integers,  etc.),  the  regular 
expressions  may  be  made  more  readable.  Figure  2.3  provides  an  example  of  this  feature. 


%define  Letter 

:  [a-zA-Z] 

%defme  Int 

:  { Digit) + 

%define  Alphanum 

:  [(Digit)  (Letter)) 

COMMENT 

:  "--".•An" 

NAME 

:  (Letter)  (Alphanum)* 

Figure  2.3 

Regular  Expressions  with  Definition  Expansion. 

d.  Attribute  Declaration  Section. 

The  attribute  declaration  section  of  a  Kodiyak  program  declares  the  attributes 
used  in  the  program  and  their  types.  In  this  version  of  Kodiyak,  no  other  statements  may 
be  present  in  this  section,  though  it  is  expected  that  declarations  of  constant  functions  and 
external  functions  and  procedures  will  eventually  be  allowed  in  this  section. 

Kodiyak  supports  two  primitive  data  types  for  attributes:  strings  and  integers. 
Strings  may  have  arbitrary  length  and  may  be  concatenated  to  form  longer  strings.  All 
simple  mathematical  functions  (i.e.,  addition,  subtraction,  multiplication  and  division) 
may  be  applied  to  integers. 

Kodiyak  also  supports  higher  order  types.  These  types  are  called  maps,  and 
define  functions  that  may  map  any  primitive  type  to  any  other  type.  Maps  are  extremely 
flexible  and  important  to  the  type  checker.  They  can  be  mapped  onto  other  maps  to  form 
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something  similar  to  high  level  languages  record  structures.  Figure  2.4  shows  a  some 
sample  attribute  declarations. 


ID  ( 

type 

:  string; 

%text 

:  string; 

%line 

:  int; 

value 

:  int; 

} 

EXPR  ( 

type 

;  string; 

1 

e_valid 

:  string  ->  int; 

Figure  2.4 

Sample  Attribute  Declarations. 


This  figure  declares  that  four  attributes  (type,  %text,  %line  and  value)  are  to 
be  associated  with  the  grammar  symbol  ID  and  that  two  attributes  (type  and  e_valid)  are 
to  be  associated  with  expressions  (EXPR).  Furthermore,  attributes  type  and  %text  are 
attributes  that  may  take  on  string  values;  %line  and  value  may  take  on  integer  values  and 
attribute  e_valid  is  a  map  from  a  string  ("true"  or  "false")  to  an  integer  value  (1  or  0). 

Figure  2.4  also  demonstrates  two  very  important  concepts  in  Kodiyak.  First, 
since  an  identifier  (ID)  is  normally  a  terminal  symbol  and  an  expression  (EXPR)  is  a 
non-terminal,  both  terminals  and  non-terminals  can  have  attributes.  Secondly,  terminal 
symbols  can  have  two  special,  predefined  attributes  associated  with  them,  "%text"  and 
"%line".  These  attributes  are  initialized  when  the  terminal  symbol  is  recognized  to  be  the 
actual  text  scanned  and  the  input  line  on  which  the  text  was  found. 


e.  The  Attribute  Grammar  and  Semantic  Function  Section. 

The  final  section  of  a  Kodiyak  program  defines  the  syntax  and  semantics  of 
the  translation.  It  consists  of  a  set  of  rules  and  sets  of  equations  defining  evaluation  rules 
for  the  attributes.  There  is  one  distinct  start  symbol  for  the  roles  and  it  is  defined  as  the 
symbol  on  the  left  hand  side  of  the  first  role  in  the  grammar.  This  symbol  is  unique  and 
it  may  not  appear  on  the  right  hand  side  of  any  rule  in  the  grammar. 

Rules  in  Kodiyak  are  defined  in  a  form  that  is  very  similar  to  Bachus-Naur 
Form  (BNF).  Figure  2.5  defines  a  role  which  specifies  that  the  non-terminal  symbol 
"non"  will  be  recognized  if  the  symbols  "syml",  "sym2"  and  "sym3"  appear  in  sequence. 
Additionally,  if  the  symbol  ’non”  is  recognized,  the  semantic  functions  defined  between 
the  curly  braces  will  be  computed  during  the  attribute  evaluation  process. 

non  :  syml  sym2  sym3 

{ 

!  semantic  functions  go  here. 

) 

Figure  2.5 
Rule  Template. 

The  semantic  functions  must  have  a  way  of  specifying  exactly  what  attributes 
are  to  be  used  during  the  determination  process.  In  Figure  2.6  one  role  has  been  used  to 
demonstrate  the  three  different  ways  of  accessing  the  same  attributes.  In  the  first  part  of 
the  rule,  a  production  allowing  an  expression  to  be  recognized  when  two  expressions  are 
separated  by  a  plus  ("+")  sign  is  detailed.  Associated  with  it  is  a  semantic  function 
stating  the  value  attribute  of  the  expression  on  the  left  hand  side  of  the  rule  (specified  by 


the  ''$$.value"  notatic..)  will  be  assigned  the  contents  of  the  first  expression’s  value 
attribute  ("$l.value”)  added  to  the  contents  of  the  second  expression’s  value  attribute 
(’’$3. value").  The  second  and  third  notation  show  the  exact  same  effect  using 
subscripting.  In  these  examples,  the  subscript  refers  to  each  occurence  of  the  non¬ 
terminal.  If  a  subscript  is  left  out,  as  in  the  second  notation,  the  non-terminal  is  assumed 
to  refer  to  the  non-terminal  on  the  left  hand  side  of  the  equation. 


expr  expr  ’+’  expr 

{ 

S$.  value  =  SI.  value  +  S3.value 

1 

I  expr  ’-’  expr 

{ 

expr.value  =  expr[2].value  -  expr[3].value 

} 

I  expr  expr  %prec  multiply 

{ 

expr[l].value  =  expr[2].value  *  expr[3].value 

) 


Figure  2.6 

Attribute  Naming  and  Rule  Concepts. 


Kodiyak  has  a  rich  set  of  operators.  Besides  the  various  arithmetic  and  string 
operators  detailed  previously,  it  also  provides  nine  logical  operators.  Figure  2.7 
enumerates  all  of  the  operators  that  are  presendy  available. 


« 
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Ooerator  Svmbol 

Meanine. 

* 

Multiplication 

- 

Subtraction 

1 

Division 

A 

Concatenation 

□ 

Concatenation 

< 

Less  than 

> 

Greater  than 

== 

Equal  to 

<> 

Not  equal  to 

<= 

Less  than  or  equal  to 

>= 

Greater  than  or  equal  to 

&& 

Logical  and 

ii 

Logical  Or 

- 

Logical  negation 

Figure  2.7 
Kodlyak  Operators. 


Kodiyak  also  provides  a  means  of  specifying  a  statement  equivalent  to  the 
"IF"  construct  used  in  high  level  languages.  This  construct  has  different  syntax  than  most 
languages,  but  is  logically  equivalent.  Figure  2.8  demonstrates  this  construct  using  the 
"expr"  rule  introduced  in  Figure  2.6. 
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expr 

expr  T  expr 

( 

$$. value  =  ($3. value  o  0 

->  S 1  .value  /  S3,  value 

#  s2i("0") 

} 

Figure  2.8 

Kodlyak  "lf..Then..Eise"  Construct. 


The  above  example  assigns  to  the  value  attribute  of  the  left  pan  symbol  the 
contents  of  the  first  expression  divided  by  the  contents  of  the  second  expression  if  the 
contents  of  the  second  expression  are  not  equal  to  zero.  If  the  second  expression’s 
contents  are  equal  to  zero,  a  value  of  0  is  assigned  to  the  resultant  expression’s  "value" 
attribute.  The  "else"  ("#")  clause  also  introduces  another  very  important  feature  of 
Kodiyak-built  in  functions.  In  Figure  2.8,  the  string  to  integer  ("s2i")  function  was 
called  to  convert  a  string  value  into  an  integer.  Kodiyak’s  standard  functions  are 
enumerated  in  Figure  2.9. 
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Function  Name 

Puroose 

fmtfformaurgl,...) 

Generates  a  string  in  the  format  defined  by  the 
"format"  parameter,  with  argl,...  substituted. 

i2s(integer) 

Converts  an  integer  value  to  a  string  representation. 

s2i(string) 

Converts  a  character  string  to  an  integer. 

len(string) 

Returns  the  length  of  a  string. 

inputfile(0) 

Returns  a  string  naming  the  input  file. 

outputfile(0) 

Returns  a  string  naming  the  output  file. 

basename(file:  string) 

Returns  a  copy  of  a  string  without  dotted  extension. 

%output(val:string) 

Val  is  written  to  the  standard  output 

%error(val:string) 

Val  is  written  to  the  standard  error. 

%assert(condition:boolean, 
message :  string) 

If  the  value  of  condition  is  false,  Kodiyak  prints 
message  to  the  standard  error  file  and  terminates, 
otherwise,  the  procedure  does  nothing. 

%outfile(name :  string, 
val :  string) 

Val  is  written  onto  the  file  "name". 

If  name  is  null,  val  goes  to  stdout. 

%errfile(name :  string, 
val :  string) 

Val  is  written  into  the  file  "name”. 

If  name  is  Null,  val  goes  to  stderr. 

Figure  2.9 
Kodiyak  Functions. 


/.  Using  the  Kodiyak  Translator. 

The  Kodiyak  compiler  creates  and  processes  many  files.  Among  them  are 
files  that  are  processed  by  YACC,  LEX,  and  by  the  C  compiler.  The  Kodiyak 
compilation  process  also  depends  upon  two  predefined  files.  The  first  is  the  Kodiyak 
library.  This  contains  functions  for  creating  the  parse  tree,  evaluating  attributes. 
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concatenating  strings,  etc.  The  second  file  is  the  user  library.  This  is  a  set  of  C  functions 
that  the  programmer  may  define  for  himself. 

The  command  to  invoke  the  Kodiyak  translator  is  "k  program.k"  where 
"program.k"  is  the  kodiyak  program  to  be  compiled.  Files  to  be  compiled  should  have 
the  extension  "Jc"  or  the  compiler  may  not  accept  it  Kodiyak  programs  may  also  have 
the  extension  ".m4"  if  the  program  is  to  be  run  through  the  macro-preprocessor  prior  to 
Kodiyak  compilation. 

After  the  program  is  compiled,  (assuming  no  errors  are  present),  the  resulting 
object  code  will  be  in  the  file  "program"  in  the  cuirent  directory. 

D.  THE  SPEC  LANGUAGE. 

SPEC  is  a  formal  language  for  writing  black-box  specifications  for  components  of 
software  systems.  SPEC  uses  the  event  model  to  define  the  black-box  behavior  of 
proposed  and  external  systems.  Black-box  specifications  are  developed  for  the  external 
interfaces  of  the  system  in  the  functional  specification  stage  of  software  development, 
and  for  the  internal  interfaces  in  the  architectural  design  stage.  Discussion  of  the  event 
model  and  the  SPEC  language,  extracted  from  [Ref.  l:pp.  3.1-3.15],  follows.  Appendix 
A  and  [Ref.  1]  contain  a  listing  of  the  grammar  for  the  SPEC  language. 

1.  The  Event  Model. 

In  the  event  model,  computations  are  described  in  terms  of  events,  modules  and 
messages.  An  event  occurs  when  a  message  is  received  by  a  module  at  a  particular 
instant  of  time.  A  module  is  a  black  box  that  interacts  with  other  modules  only  by 
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sending  and  receiving  messages.  A  message  is  a  data  packet  that  is  sent  from  one 
module  to  another  module. 

Modules  can  be  used  to  model  external  systems  such  as  users  and  peripheral 
hardware  devices,  as  well  as  software  components.  A  module  has  no  visible  internal 
structure.  The  behavior  of  a  module  is  specified  by  describing  its  interface.  The 
interface  of  a  module  consists  of  the  kinds  of  events  that  can  occur  at  the  module  along 
with  its  response  to  each  kind  of  event.  Each  kind  of  event  corresponds  to  a  different  of 
incoming  message.  Each  response  consists  of  the  later  events  directly  triggered  by  a 
given  initial  event. 

Any  module  accepts  messages  one  at  a  time,  in  a  well-defined  order  that  can  be 
observed  as  a  computation  proceeds.  Message  transmission  is  assumed  to  be  reliable. 
Messages  can  have  arbitrarily  long  and  unpredictable  transmission  delays.  The  order  of 
messages  arriving  is  normally  not  under  control  of  the  designer. 

In  the  event  model  each  module  has  its  own  local  clock.  The  local  clocks  of 
different  modules  are  not  necessarily  synchronized  with  each  other.  Each  event  occurs  at 
a  well-defined  instant  of  time,  which  is  the  time  at  which  the  destination  module  receives 
a  message,  according  to  its  own  local  clock.  The  length  of  time  between  two  events  is 
precisely  defined  if  both  events  occur  at  the  same  place.  The  length  of  time  between  two 
events  at  different  locations  can  be  estimated  in  terms  of  two  readings  of  the  same  clock, 
but  this  is  only  an  approximation  because  of  unpredictable  message  delays  in  obtaining 
remote  clock  readings.  The  only  kind  of  time  interval  meaningful  in  the  event  model  is 
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the  duration  between  two  events.  There  is  no  way  to  distinguish  between  computation 
delay  and  communication  delay  in  the  event  model. 

Each  message  has  a  sequence  of  zero  or  more  data  values  associated  with  it.  The 
other  attributes  of  a  message  are  its  name,  its  condition  and  its  origin.  All  of  these 
attributes  are  single  valued.  Exceptions  are  modeled  as  messages  by  means  of  a 
condition  attribute,  which  can  take  on  the  values  "normal"  and  "exception".  The 
condition  of  a  message  expressing  a  normal  request  for  service  is  "normal".  The 
condition  of  a  message  reporting  an  abnormal  event  somewhere  is  "exception",  in  which 
case  the  name  of  the  message  is  the  name  of  an  exception  condition. 

The  response  of  a  module  to  a  message  is  completely  determined  by  the  sequence 
of  messages  received  by  the  module  since  it  was  created.  A  module  is  mutable  if  the 
response  of  the  module  to  at  least  one  message  it  accepts  can  depend  on  messages  that 
arrived  before  the  most  recent  incoming  message.  A  module  is  immutable  if  the  response 
of  the  module  to  every  possible  message  is  completely  determined  by  the  most  recent 
incoming  message.  Mutable  modules  behave  as  if  they  had  internal  states  or  memory, 
while  immutable  modules  behave  like  mathematical  functions.  A  module  is  immutable  if 
and  only  if  it  is  not  mutable. 

Each  module  has  the  potential  of  acting  independently,  so  that  there  is  natural 
concurrency  in  a  system  consisting  of  many  modules.  Since  events  happen 
instantaneously  and  the  response  of  a  module  is  not  sensitive  to  anything  but  the 
sequence  of  events  at  the  module,  the  event  module  implies  concurrent  interactions  with 
a  module  cannot  interfere  with  each  other  at  the  level  of  individual  events.  This  non- 
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interference  must  be  guaranteed  by  implementations  which  require  a  finite  time  interval 
to  trigger  the  responses  to  an  event.  The  response  of  a  module  is  under  the  control  of  the 
designer. 

In  modeling  concurrent  systems  it  is  sometimes  necessary  to  specify  atomic 
transactions.  Atomic  transactions  are  non-interruptible  sequences  of  events  at  a  module. 
Once  a  module  starts  an  atomic  transaction,  it  cannot  accept  any  messages  that  are  not 
part  of  the  transaction  until  it  is  complete.  Atomic  transactions  are  sometimes  needed  to 
specify  non-interference  between  concurrent  sets  of  activities  involving  chains  of 
multiple  events  at  the  same  module.  Atomic  transactions  must  be  used  with  care  because 
they  can  lead  to  deadlocks  if  the  protocols  of  the  modules  involved  in  a  transaction  are 
not  compatible  with  each  other,  and  can  lead  to  starvation  if  a  transaction  goes  on 
forever. 

Modules  can  be  used  to  model  current  and  distributed  systems,  as  well  as  systems 
consisting  of  a  single  sequential  process.  The  event  model  help’s  to  expose  the 
parallelism  inherent  in  a  problem,  because  the  only  time  orderings  specified  are  those 
which  are  unavoidable  and  are  agreed  on  by  all  observers. 

Events  can  be  triggered  at  absolute  times.  Such  events  are  called  temporal  events. 
Temporal  events  are  the  means  by  which  modules  can  initiate  actions  that  are  not  direct 
responses  to  external  stimuli.  Formally  a  temporal  event  occurs  when  a  module  sends  a 
message  to  itself  at  a  time  determined  by  its  local  clock.  Unless  explicitly  stated 
otherwise,  there  may  be  an  unpredictable  delay  between  the  time  when  the  message  is 
sent  and  the  time  when  it  is  received,  just  like  for  any  other  message. 
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2.  The  SPEC  Language. 

The  SPEC  language  uses  second  order  logic  for  the  precise  definition  of  the 
desired  behavior  of  modules.  The  Spec  language  provides  a  means  for  specifying  the 
behavior  of  three  different  types  of  modules: 

(1)  Functions 

(2)  State  machines 

(3)  Types 

Each  of  these  types  of  modules  is  described  in  the  following  pages  along  with 
examples  of  each  type  of  module. 

a.  Functions. 

Function  modules  are  immutable  and  calculate  functions  on  data  types,  where 
"function"  is  interpreted  as  in  standard  mathematics.  Usually  function  modules  provide 
only  a  single  service  and  hence  accept  anonymous  messages.  Figure  2.10  gives  an 
example  of  the  specification  for  a  square  root  function. 


29 


FUNCTION  square_root{precision:real) 
WHERE  precision  >  0.0 


MESSAGE  (x:real) 

WHEN  x>=  0.0 
REPLY  (y:real) 

WHERE  y  >-  0.0  &  approximates  (y*y,x) 

OTHERWISE  REPLY  EXCEPTION  imaginary _square_rool 

CONCEPT  approximates  (rl  r2:real) 

-True  if  rl  is  a  sufficiently  accurate 
-approximating  of  r2. 

-The  precision  is  relative  rather  than  absolute 
VALUE  (b:  boolean) 

WHERE  b<=>  abs  ((rl  -  r2)/r2)  <=  precision 
END 

Note: introduces  a  comment  and  ail  keywords 
in  Spec  appear  in  all  capital  letters 

Figure  2.10 
Function  Example. 


b.  State  Machines. 

A  machine  is  a  module  with  an  internal  state,  i.e.,  machines  are  mutable 
modules.  Figure  2. 1 1  shows  an  example  of  a  machine.  The  behavior  of  the  machines  is 
described  in  terms  of  a  conceptual  model  of  its  state,  rather  than  directly  in  terms  of  the 
messages  that  arrived  in  the  past,  because  descriptions  in  terms  of  such  a  conceptual 
model  are  usually  shorter  and  easier  to  read. 
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MACHINE,  inventory 

—assumes  that  shipping  and  supplier  are  other  modules 
STATE  (stock:map(item, integer}) 

INVARIANT  ALL  (i:item::stock[l]  >=  0) 

INITIALLY  ALL  (i:item::stock[l]  =  0) 

MESSAGE  receive  (i:item,q:integer) 

-Process  a  shipment  from  a  supplier. 

WHEN  q  >  0 

TRANSITION  stock(l]=*stack[i]  +  q 
-Delayed  responses  to  backorders  are  not  shown. 
OTHERWISE  REPLY  EXCEPTION  empty _shi pm ent 

MESSAGE  order  (io:item,qo: integer) 

-Process  an  order  from  a  customer. 

WHEN  0  <  qo  <=  stock[io] 

SEND  ship  (is’.item,  qs: integer)  TO  shipping 
WHERE  is  =  io,  qs  =  qo 
TRANSITION  stockfio]  +  qo  =  *stock[io] 

WHEN  0  <  qo  >  stock[io] 

SEND  ship  (isritem,  qs:integer)  TO  shipping 
WHERE  is  =  is,  qs  =  stockfio] 

SEND  back_order  (ib:item,  qb:  integer)  TO  supplier 
WHERE  ib  =  io,  qb  +  qs  =  qo 
TRANSITION  stockfio]  =  0 
OTHERWISE  REPLY  EXCEPTION  empty_order 
END 


Flgure2.ll 
Machine  Example. 


c.  Types 

A  type  module  defines  an  abstract  data  type.  An  abstract  data  type  provides 
many  services  therefore  the  messages  of  a  type  module  usually  have  a  name.  An  abstract 
data  type  consists  of  a  set  of  instances  and  a  set  of  primitive  operations  involving  the 
instances.  The  instances  are  the  individual  data  objects  belonging  to  the  type.  The 
instances  of  an  abstract  data  type  are  black  boxes.  The  properties  of  the  instances  are  not 
visible  directly,  and  can  only  be  observed  and  influenced  by  means  of  the  primitive 
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operations.  The  properties  of  an  instance  are  determined  by  the  primitive  .operation  that 
created  the  instance  and  the  sequence  of  primitive  operations  applied  after  it  was  created. 

Data  types  are  either  mutable  or  immutable.  For  immutable  types  the  set  of 
instances  and  the  properties  of  each  instance  are  fixed.  Operations  producing  instances 
of  the  type  are  viewed  as  selecting  members  of  this  fixed  set  Figure  2.12  is  an  example 
of  an  immutable  abstract  data  type. 


TYPE  rational 
INHERIT  equality  (rational) 

MODEL  (num  den.integer) 

INVARIANT  ALL  (r:rational::r.den  ~=  0) 

MESSAGE  ratio  (num  den:integer) 

WHEN  den  ~=  0 
REPLY  (nrational) 

WHERE  r.num  =  num,  r.den  =  den 
OTHERWISE  REPLY  EXCEPTION  zero_denom inator 

MESSAGE  add  (x,y:rational)  OPERATOR  + 

REPLY  (nrational) 

WHERE  r.num  =  x.num*y.den+y.num*x.den, 
r.den  =■  x.den*y.den 

MESSAGE  multiply  (x  y.rational)  OPERATOR  * 
REPLY  (nrational) 

WHERE  r.num  =  x.num*y.num,  r.den  =  x.den*y.den 

MESSAGE  equal  (x  yirational)  OPERATOR  = 

REPLY  (b:boolean) 

WHERE  b  <=>  (x.num*y.den  =  y.num*x.den) 

END 


Figure  2.12 

Immutable  Abstract  Data  Type. 


The  state  of  a  mutable  data  type  consists  of  a  set  of  instances  which  have 
internal  states.  The  initial  state  of  a  mutable  type  is  an  empty  set  of  instances.  Mutable 


types  have  operations  for  creating  new  instances,  and  usually  also  operations  that  can 
change  the  properties  of  an  instance  once  it  has  been  created.  An  example  of  a  mutable 
abstract  data  type  with  immutable  instances  is  the  set  of  unique  identifiers  for  the  objects 
in  a  database. 

An  instance  of  a  mutable  data  type  is  very  similar  to  a  state  machine,  except 
that  the  state  machine  is  implicitly  created  at  the  start  of  the  computation,  while  the 
instances  of  a  mutable  data  type  are  created  as  a  computation  proceeds.  A  state  machine 
has  exactly  one  instance,  while  a  mutable  data  type  can  have  any  number  of  instances. 
Figure  2.13  is  an  example  of  a  specification  of  a  mutable  data  type. 
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TYPE  queue  (tttype) 

INHERIT  mutable  (queue) 

-Inherit  definitions  of  the  concepts  new  and  defined. 
MODEL  (e:sequence) 

-The  front  of  the  queue  is  at  the  right  end. 
INVARIANT  tue 

--Any  sequence  is  a  valid  model  for  a  queue. 

MESSAGE  create 
--A  newly  created  empty  queue. 

REPLY  (q:queue(t))  WHERE  q.e  =  0 
TRANSITION  new(q) 

MESSAGE  enqueue  (x:t,  q-.queue(t)) 

-Add  x  to  the  back  of  the  queue. 

TRANSITION  q.e  =  append([x],  *q.e) 

MESSAGE  dequeue  (q:queue{t)) 

-Remove  and  return  the  front  element  of  the  queue. 
WHEN  nonempty  (q) 

REPLY  (x:t) 

TRANSITION  *q.e  =  append  (q,e,[x]) 

OTHERWISE  REPLY  EXCEPTION  queue_underflow 

MESSAGE  nonempty  (q:queue{t)) 

-True  if  q  is  not  empty. 

REPLY  (b:boolean)  WHERE  b  <=>  (q.e  ~=  Q) 

END 


Figure  2.13 

Mutable  Abstract  Data  Type. 


HL  SYSTEM  DESIGN. 


The  first  stage  of  the  design  effort  was  to  analyze  the  requirements  and  obtain  a  better 
understanding  of  the  SPEC  language.  To  facilitate  this  process,  a  language  reference 
manual  [Ref.  19]  was  developed.  Ttus  language  reference  manual  describes  many  of  the 
finer  points  in  the  SPEC  language  and  provided  a  firm  starting  point  for  the  type  checker. 
It  assisted  in  illuminating  many  of  the  issues  that  would  have  to  be  addressed  in  the 
design  and  capabilities  that  the  type  checker  would  have  to  encompass. 

A.  SPEC  LANGUAGE  TYPE  CONSISTENCY  CONSTRAINTS. 

Like  most  computer  languages,  SPEC  has  many  constraints  on  the  naming  and  use  of 
various  operands.  These  constraints  were  derived  from  [Ref.  1]  and  [Ref.  19]. 

1.  SPEC  Language  Semantic  Issues. 
a.  Definitions. 

•  Descendant  of  a  Module:  A  module  is  considered  to  be  a  descendant  of  another 
module  if  it  explicitely  inherits  the  traits  of  that  module  using  an  INHERIT 
clause. 

•  Local:  A  name  is  local  if  it  is  only  visible  to  the  module  /  entity  in  which  it  is 
contained. 

•  Global:  A  name  is  global  if  it  is  visible  to  the  entire  specification. 

•  Signature:  The  signature  of  a  name  is  the  ordered  set  consisting  of  the  actual 
name,  the  arguments  associated  with  that  name  and  the  types  associated  with  the 
arguments. 

•  Boolean  Value:  A  value  that  may  only  take  on  the  logical  values  of  "true"  or 
"false". 


•  Unique  Definition  Constraint:  Only  one  definition  of  a  concept  or  message 
with  the  same  signature  is  allowed  to  be  visible  in  any  of  the  modules  in  a  well 
formed  specification. 

•  Definition  Consistency  Constraint:  Some  concepts  may  have  to  be  renamed 
before  they  can  be  imported  or  inherited. 

•  Import  Consistency  Contraint:  A  concept  can  be  imported  from  another 
module  only  if  the  other  module  defines  and  EXPORT’S  the  concept. 

•  Instance  Consistency  Constraint:  Requires  that  the  actual  parameters  of  an 
instance  of  a  generic  module  must  satisfy  any  constraints  mentioned  in  the 
WHERE  clause  after  the  generic  parameter  declaration. 

•  Input  Coverage  Constraint:  Requires  every  concept  to  have  proper  values  for 
all  possible  inputs  satisfying  die  precondition.  Also,  the  WHERE  and 
TRANSITION  clauses  of  each  message  must  have  proper  values  for  all  states 
and  input  values  satisfying  the  associated  preconditions. 

•  Congruence  Consistency  Constraint:  A  property  of  MESSAGES  and 
CONCEPTS  that  is  true  if  they  mean  the  same  thing  for  all  equivalent  conceptual 
representations. 

•  Completed  Specification:  A  specification  that  meets  all  of  the  Constraints  and 
scoping  requirements  of  the  SPEC  language  and  contains  no  instances  of  the  not 
yet  defined  clause  ("?"). 

b.  Scoping. 

•  The  names  of  MODULES  are  global  and  unique.  No  module  name  may  be 
redeclared  at  any  other  point  in  the  specification. 

•  The  names  of  MESSAGES  and  EXCEPTIONS  are  global. 

•  The  names  of  CONCEPTS  are  local  to  the  module  in  which  they  are  defined. 
Concepts  may  be  inherited  by  another  module  with  the  use  of  an  INHERIT 
clause  in  that  module.  A  Concept  may  only  be  associated  with  other  modules  if: 

(a)  It  is  explicitly  exported  with  an  EXPORT  clause  and 

(b)  It  is  explicitly  imported  into  the  module  it  is  to  be  associated  with  by  an 
IMPORT  clause. 

•  The  FORMAL  PARAMETERS  of  a  generic  module  are  visible  in  the  module  in 
which  these  names  are  defined. 


36 


•  The  component  names  of  the  MODEL  of  a  type  are  visible  in  the  module  in 
which  the  names  are  defined  and  in  any  descendants  of  that  module. 

•  The  component  name  of  the  STATE  of  a  machine  are  visible  in  the  module  in 
which  the  names  are  defined  and  in  any  descendants  of  that  module. 

•  The  FORMAL  PARAMETERS  of  a  message  are  visible  to  the  entire 
specification  of  that  message. 

•  The  FORMAL  ARGUMENTS  of  a  message  are  visible  to  the  entire  specification 
of  that  message. 

•  The  FORMAL  ARGUMENTS  of  a  reply  clause  are  visible  from  their  declaration 
to  the  end  of  the  when  or  otherwise  clause  in  which  they  are  declared.  If  no 
when  or  otherwise  clause  exists,  they  are  visible  until  the  end  of  the  message 
specification. 

•  The  FORMAL  ARGUMENTS  of  a  send  clause  are  visible  from  their  declaration 
to  the  end  of  the  when  or  otherwise  clause  in  which  they  are  declared.  If  no 
when  or  otherwise  clause  exists,  they  are  visible  until  the  end  of  the  message 
specification. 

•  The  FORMAL  ARGUMENTS  of  a  generate  clause  are  visible  from  their 
declaration  to  the  end  of  the  when  or  otherwise  clause  in  which  they  are  declared. 
If  no  when  or  otherwise  clause  exists,  they  are  visible  until  the  end  of  the 
message  specification. 

•  The  visibility  of  LOCAL  VARIABLES  declared  in  a  CHOOSE  clause  extends 
from  their  declaration  to  the  end  of  the  when  or  otherwise  clause  in  which  they 
are  declared.  If  no  when  or  otherwise  clause  exists,  they  are  visible  until  the  end 
of  the  message  specification. 

•  The  scope  of  variables  bound  to  a  quantifier  extends  from  the  "("  following  the 
name  of  the  quantifier  to  the  matching 

•  All  identifiers  in  SPEC  must  fall  into  one  of  the  above  categories. 

c.  Naming  Constraints. 

•  The  name  of  a  module  is  considered  unique  if  there  is  only  one  module  defined 
with  its  given  name. 

•  The  name  of  a  message  is  considered  unique  if  there  is  only  one  occurrence  of 
that  name  with  it’s  specific  signature  within  its  scope. 


37 


•  The  operator  of  a  message  is  considered  unique  if  there  is  only  one  occurrence  of 
that  operator  with  the  specific  signature  of  its  corresponding  name  within  the 
operators  scope. 

•  The  name  of  a  concept  is  considered  unique  if  there  is  no  other  definition  of  that 
name  with  the  same  signature  within  the  name’s  scope. 

•  Any  other  name  construct  is  considered  unique  if  there  is  no  other  occurence  of 
that  name  within  its  defined  scope. 

d.  Type  Consistency  Constraints. 

•  An  operation  which  is  referenced  to  a  specific  module  with  the  "(©module" 
qualifier  must  be  defined  (or  inherited  by)  the  referenced  module. 

•  If  the  "@module"  qualifier  is  not  used  to  clarify  the  use  of  an  operator  or 
message  name,  there  must  be  exactly  one  candidate  operation  matching  the  types 
of  the  actual  parameters. 

•  Arguments  and  Parameters  in  SPEC  are  specified  by  position.  If  a  value  or  name 
is  given  for  the  arguments  or  parameters  used  in  a  call  to  a  construct  (the  actual 
parameters),  the  types  of  the  names  or  value  must  match  the  corresponding 
formal  parameters  or  arguments. 

•  There  must  be  a  unique  correspondence  between  the  actual  parameters  and  the 
formal  parameters.  For  example,  if  the  $  operator  is  used  to  specify  a  variable 
number  of  parameters  in  the  formal  definition,  it  must  be  determinable  as  to 
which  actual  parameters  the  $  will  be  bound. 

•  An  expression  following  a  WHERE  clause  must  evaluate  to  a  boolean  value. 

•  An  expression  following  a  WHEN  clause  must  evaluate  to  a  boolean  value. 

•  An  expression  following  a  SUCH  THAT  clause  must  evaluate  to  a  boolean 
value. 

•  An  expression  following  an  IF  or  ELSE_IF  clause  must  evaluate  to  a  boolean 
value. 
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•  The  types  of  the  expression  following  the  specification  of  a  quantifier  must 
match  the  requirements  of  the  quantifier.  Predefined  constraints  are: 

ALL  Boolean 

SOME  Boolean 

NUMBER  Any  type  with  an  equality  operator. 

SUM  Any  type  with  a  commutative  &  associative  "+"  operation. 

PRODUCT  Any  type  with  a  commutative  &  associative  operation. 

UNION  Any  type  with  a  commutative  &  associative  union. 

INTERSECT.  Any  type  with  a  commutative  &  associative  intersection. 

MAXIMUM  Any  type  with  a  partial  order  "<="  operation. 

MINIMUM  Any  type  with  a  partial  order  "<="  operation. 

•  The  expressions  on  either  side  of  a  conditional  operator  must  be  of  the  same 
type. 

•  All  of  the  normal  REPLY  clauses  of  the  same  message  must  be  of  the  same  type. 

•  All  of  the  REPLY  EXCEPTION  clauses  with  the  same  exception  condition  in  the 
same  message  must  be  of  the  same  type. 

•  The  definition  of  each  message  used  in  an  expression  must  not  contain  any 
TRANSITION  clauses. 

•  If  a  SPEC  predefined  operator  is  overloaded,  the  overloading  message  must  have 
the  same  number  of  arguments  as  the  defined  operator  in  the  SPEC  library.  For 
example,  the  "+"  operator  cannot  be  overloaded  to  a  message  that  requires  three 
arguments. 

B.  CONCEPTUAL  MODEL. 

1.  Requirements. 

The  SPEC  type  consistency  constraints  identified  many  different  requirements  for 
the  type  checker.  The  more  distinct  requirements  are: 

•  When  a  name  is  used  in  the  specification,  all  defined  argument  lists  for  that  name 
must  be  searched  to  determine  the  correct  signature  for  that  usage.  If  more  than 
one  possible  matching  signature  is  found,  an  error  message  must  be  reported 
listing  all  the  conflicting  usages.  Figure  3.1  shows  three  skeleton  modules.  In 
the  first  two  modules  define  two  types,  "nat"  and  "integer".  They  also  define  two 
messages,  "add",  each  of  which  is  a  legal  definition  within  its  scope.  The  third 
module  uses  the  "add”  message.  During  the  type  checking  process,  an  error  must 


be  reported  in  function  "does_something"  stating  that  more  than  one  possible 
signature  match  for  the  "add"  message  exists  and  reporting  the  conflicting 
bindings. 


TYPE  nat 
MODEL 

INVARIANT  true 


MESSAGE  add  (n  :  nat,  i :  integer) 

REPLY  (i 2  :  integer)  WHERE  i2  =  i  +  n 

END 


TYPE  integer 
MODEL 

INVARIANT  true 

MESSAGE  add  (n :  nat,  i :  integer) 

REPLY  (i2  :  integer)  WHERE  i2  =  i  +  n 

END 


FUNCTION  does_something 
MESSAGE  0  :  integer,  n  :  nat) 

REPLY  (i2 :  integer)  WHERE  i2  =  add(n,i) 

END 


Figure  3.1 

Conflicting  Name  Bindings. 


•  A  data  structure  must  be  available  at  all  times  which  retains  the  names,  signature, 
operator(s),  module  name,  return  type  and  parameters  for  each  message  in  the 
specification. 

•  A  data  structure  must  be  available  during  importation  which  retains  the  names, 
signature,  module  name,  return  type  and  parameters  for  each  exported  concept  in 
the  specification. 

•  During  name  analysis,  all  module  names  must  be  examined  prior  to  the 
examination  of  any  other  name.  The  examination  of  message  names,  concept 
names,  a  module’s  formal  parameters  and  the  state  or  model  clause  variables 
should  then  be  accomplished  in  order. 

•  Any  variable  names  or  types  declared  within  any  other  SPEC  structure  are  visible 
within  that  structure  only  subject  to  defined  visibility  rules. 
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•  The  type  of  every  visible  name  must  be  immediately  determinable  during  the 
type  checking  process  to  enable  type  consistency  checking. 

•  Every  name  must  be  unique  according  to  its  scope  and  signature.  If  a  name  is 
not  unique,  an  error  must  be  reported. 

•  All  the  formal  arguments  and  parameters  of  a  name  must  be  retained  in  full  (i.e., 
the  "type"  and  the  name  saved)  in  order  to  facilitate  proper  checking  of  variable 
argument  or  parameter  lists.  In  this  way,  if  the  name  is  bound  within  the  actual 
arguments  or  parameters,  it  is  determinable  which  formal  argument  or  parameter 
is  associated  with  that  name. 

2.  Model. 

Based  on  these  requirements,  a  design  was  developed  that  provided  an  efficient 
solution.  The  cornerstone  of  this  design  was  the  means  in  which  a  signature  lookup  was 
accomplished.  The  best  solution  this  research  found  was  to  have  a  map  from  a  name  to  a 
set  of  tuples.  Each  tuple  in  this  set  represents  one  distinct  overloading  of  the  name  in  the 
domain  of  the  map.  By  searching  this  set  of  tuples,  the  specific  overloading  which  is 
being  used  can  be  found. 

To  provide  an  efficient  means  for  information  lookup,  each  tuple  in  this  set 
contains  a  list  and  a  number.  The  list  is  an  ordered  list  of  tuples  and  each  tuple  in  the  list 
contains  information  on  one  of  the  formal  arguments  in  the  signature.  The  number  is  a 
value  or  cross  reference  that  when  "looked  up"  in  the  symbol  table  provides  immediate 
access  to  all  information  concerning  that  symbol. 

The  tuple  representing  one  of  the  formal  arguments  or  formal  parameters  consists 
of  two  elements-the  name  of  that  element  and  its  "type".  The  "type"  that  is  placed  in 
this  second  element  is  derived  from  a  map  which  has  a  domain  consisting  of  all  the  types 
that  are  visible  at  that  point  and  a  range  consisting  of  a  translated  text  for  that  specific 
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type.  The  translated  text  is  simply  a  modified  version  of  the  actual  type  name.  If  a  type 
name  belongs  to  a  concept,  it  is  local  to  the  current  module,  so  an  symbol  is 
appended  to  the  name  followed  by  the  current  module’s  name.  If  the  type  name  belongs 
to  a  module,  the  range  matches  the  domain.  In  this  way,  if  a  concept  is  defined 
differently  in  two  different  modules  the  "relationships"  (e.g.,  messages,  etc.)  between  the 
modules  must  use  the  concept  they  were  defined  with  and  not  the  corresponding  concept 
in  the  other  module.  In  Figure  3.2  the  two  types  of  entries  permitted  in  the  "type"  map 
and  the  module  that  defines  them  are  shown. 


TYPE  complex 

MODEL  ( re  :  real,  im  :  imaginary _part) 

INVARIANT 

CONCEPT  imaginary_part :  type 

WHERE  imaginary _part  =  real 

END 

Actual  Name 

Translated  equivalent. 

complex 

complex 

imaginary  _part 

imaginary  _part@complex 

Figure  3.2 

Limiting  Type  Visibility. 


Based  on  these  features,  the  symbol  table  becomes  a  map  from  the  cross  reference 
value  to  a  tuple.  This  tuple  contains  the  required  information  for  each  symbol,  its 
parameters,  class,  textual  name  and  type.  The  parameters  element  is  a  tuple  which 
represents  the  formal  parameters  (if  any)  of  the  symbol.  The  class  element  contains  some 
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representation  of  the  class  (function,  message,  concept,  etc.)  that  the  symbol  belongs  to, 
and  the  textual  name  element  contains  the  actual  text  of  the  symbol  (used  for  error 
reporting). 

While  determining  the  conceptual  model  of  the  last  element  of  this  tuple,  it  was 
noted  that  each  symbol  that  would  be  placed  in  the  symbol  table  was  either  a  variable,  a 
concept  or  message  or  a  module  name.  Interestingly  enough,  this  indicated  that  the  type 
element  of  the  tuple  contained  in  the  domain  could  have  a  dual  purpose.  If  the  symbol 
was  a  variable  or  "non-function”  concept  (a  concept  without  a  VALUE  clause),  the  actual 
type  of  that  name  could  be  placed  in  that  field.  If  the  symbol  is  a  message  or  concept 
with  a  VALUE  clause,  the  type  that  the  symbol  returns  could  be  placed  in  that  field;  and 
if  the  symbol  was  a  module  name,  no  information  needed  to  be  placed  in  that  field. 

Actually  building  these  tables  presented  another  problem.  Due  to  the  declaration 
requirement  that  a  module  name  could  not  be  redeclared  and  that  concept  and  message 
names  are  visible  throughout  the  entire  module  they  are  defined  in,  the  necessary  "name" 
table  has  to  be  built  in  three  "layers".  In  the  first  layer,  all  of  the  module  names  are 
collected  into  a  table  and  any  redeclarations  are  identified.  These  module  names  are  then 
passed  down  into  the  second  layer  during  which  all  message  and  concept  names  are 
added  to  the  table.  Additionally,  if  a  message  has  an  operator  associated  with  it,  the 
operator  can  be  treated  as  a  name  unto  itself,  with  the  same  arguments  as  the  message 
and  stored  in  the  table  accordingly. 

When  this  table  is  returned  to  the  top  of  the  semantic  tree,  one  additional  level  of 
indirection  is  added  to  it  so  that  a  name  declared  in  one  module  doesn’t  "overwrite"  the 
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identical  name  declared  in  a  different  module.  This  level  of  indirection  is  added  by 
taking  the  original  map  and  making  it  the  range  of  a  new  map  whose  domain  is  the 
module  name.  Figure  3.3  shows  this  process. 

before:  string  ->  string 

after:  module_name  ->  string  ->  string 

Figure  3.3 
Localizing  a  Map. 

The  final  layer  in  the  name  analysis  process  takes  this  table  produced  by  the 
second  layer  and  "cuts"  it  within  each  module  so  that  only  those  names  defined  in  that 
module  arc  passed  back  down.  All  other  names  that  are  encountered  within  that  module 
are  then  added  to  it,  according  to  the  scope  rules  of  the  SPEC  language.  With  the  tables 
being  "manuevered"  through  the  semantic  tree  during  this  layer,  the  type  consistency 


analysis  can  be  performed.  Additionally,  if  the  tables  produced  by  the  second  layer  arc 
passed  down  the  tree  also,  these  tables  can  be  used  to  verify  whether  a  message  exists  or 


doesn’t  exist  in  another  module.  Figure  3.4  demonstrates  this  name  layering  process. 


Laver 

Contains 

Structure 

1 

nothing,  yet. 

name  ->  tuple 

2 

module  names 

name  ->  tuple 

3 

modules,  concepts,  messages 

module  name  ->  (name  ->  tuple) 

3 

modules,  concepts,  messages 

T 

name  ->  tuple 

this  map  only  has  locals. 

Figure  3.4 
Name  Layering. 
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With  these  tables,  the  type  consistency  analysis  simplifies  to  two  distinct  parts. 
The  first  part  involves  obtaining  the  correct  symbol  from  the  tables  produced  in  the 
layering  process.  To  determine  that  only  one  unique  possibility  exists  for  this  symbol, 
both  of  the  layer  three  tables  must  be  searched--the  local  table  and  the  table  which 
contains  all  the  symbols  defined  in  other  modules.  However,  in  the  second  table,  only 
messages  need  be  examined. 

The  second  part  of  the  type  consistency  analysis  involves  checking  the  actual  type 
of  the  symbol.  Ideally,  this  should  only  be  a  "lookup"  in  the  symbol  table,  but  since  a 
message  or  concept  may  have  a  value  that  is  transitively  dependent  on  another  message 
or  concepts  routine  that  recursively  resolves  the  type  must  be  performed.  Figure  3.5 
shows  a  two  dimensional  transitive  dependency  situation.  The  first  message,  message_l, 
has  a  resultant  value  that  is  dependent  upon  a  concept,  dimension_2.  Theoretically,  this 
transitivity  could  be  repeated  extensively. 

MESSAGE  message_l  (...) 

REPLY  dimension_2  (...) 

CONCEPT  dimension_2  (...) 

VALUE  (...) 


Figure  3.5 

Result  Values  Transitive  Dependency. 

To  conclude  the  process,  the  type  is  passed  up  to  the  next  higher  level  of  the 
semantic  tree  and  used  to  resolve  that  level.  Additionally,  any  errors  encountered  are 
concatenated  onto  the  error  messages  from  the  "children"  of  the  current  level  and  also 
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passed  up.  When  the  uppermost  level  of  the  semantic  tree  receives  these  error  messages 
from  its  children,  the  type  checking  process  is  completed  and  the  errors  can  be  reported 
to  the  user. 

C.  DESIGN  CONVENTIONS. 

In  an  effort  to  increase  the  readability  of  the  source  code,  it  was  decided  that  the  M4 
macro  preprocessor  would  be  used  and  a  stardardized  attribute  naming  schema  adopted. 
The  attribute  naming  schema  assisted  in  cutting  down  the  source  code  size,  but  the  M4 
macro  preprocessor  helped  significantly  more.  The  M4  preprocessor  "shrunk"  the  actual 
code  size  almost  50%  (3926  lines  prior  to  expansion,  7591  after)  by  coalescing  multiple 
source  code  lines  into  one  line  of  M4  code. 

1.  Attribute  Naming. 

The  primary  rule  followed  in  the  naming  of  all  attributes  was  to  make  the  name  as 
descriptive  as  possible  concerning  the  purpose  of  the  attribute,  without  "exploding"  the 
size  of  the  source  code.  Additionally,  each  attribute  is  appended  with  an  underbar  (_) 
followed  by  a  descriptive  character  (s  or  i)  which  signifies  the  use  of  the  attribute 
(synthesized  or  inherited).  Some  sample  names  include  "module_name_s", 
"visible_types_i"  and  ”ip_stbl_s".  A  complete  listing  of  all  descriptive  names  is 
contained  in  Appendix  D. 

Certain  abbreviations  were  adopted  to  assist  in  the  naming,  without  making  the 
name  too  long.  Some  of  the  more  common  abbreviations  include: 
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ip  :  signifies  that  the  attribute  is  currently  "in  the  process"  of  being  built.  The 
information  currently  contained  in  this  attribute  is  not  reliable  for  any  other  purpose  than 
building  the  final  attribute  and  thus  should  not  be  used  for  any  other  purpose. 

Iclzd  :  denotes  that  a  table  is  "localized".  A  localized  table  is  normally  a  map 
with  a  domain  consisting  of  a  string  and  the  range  containing  another  map.  The  string  in 
the  domain  string  will  always  be  a  module  name  or  a  scope  related  value  (such  as 
"GLOB AL_TYPE_N AMES"  in  myconst.m4). 

stbl :  symbol  table.  Any  attribute  name  prefixed  by  this  word  denotes  an  attribute 
that  is  pan  of  the  symbol  table  group  of  attributes  (e.g.,  stbl_names). 

xref  :  cross  reference.  Any  attribute  containing  this  abbreviation  has  a  range 
which  contains  cross  reference  information  in  it  (normally  within  a  tuple).  Many  times,  a 
prefix  is  appended  to  this  word  (mxref  or  mcmxref)  to  assist  in  the  distinction  of  the 
attributes’  purpose.  Two  of  the  more  common  attributes  using  this  abbreviation  are 
mxref  (module  cross  reference)  and  mcmxref  (module-concept-message  cross  reference). 

env  :  environment.  This  abbreviation  is  commonly  used  in  attributes  that  are 
passed  down  to  non-terminals  to  "inform"  the  non-terminal  of  the  environment  within 
which  it  is  currently  being  utilized. 

2.  M4  Macro  Abstractions. 

The  actual  M4  macro  definitions  are  contained  in  three  different  files- 
"attrib_psg.m4",  "mymac.m4"  and  "myconst.m4".  Two  additional  M4  files  were  used  in 
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this  design  (head.m4  and  tail.m4)  but  they  simply  contain  certain  M4  commands  that  are 
required  so  that  M4  will  function  properly  with  the  Kodiyak  tool.  All  of  the  M4  files  are 
enumerated  in  Appendix  2. 
a.  Attrib_psg.m4. 

This  file  contains  all  the  M4  macros  that  are  associated  with  a  general 
attribute  passing  capability.  They  could  be  used  in  any  Kodiyak  program  and  are  not  at 
all  specific  to  the  type  checker.  Most  of  these  macros  have  been  derived  from  the 
"macros.m4"  file  developed  by  Robert  Herndon  and  promulgated  with  the  Kodiyak 
compiler.  Some  modifications  were  made  to  the  actual  definitions  for  the  purpose  of 
standardization,  however.  Most  of  these  modifications  involved  changing  a  macro’s 
name  to  more  accurately  reflect  how  many  attributes  were  being  passed  and  how  many 
non-terminals  these  attributes  are  passed  to. 

There  are  six  actual  groups  of  macros  within  this  file.  Each  group  is 
characterized  by  a  descriptive  name,  followed  by  two  integer  values  separated  by  an 
underbar.  The  name  details  the  purpose  of  the  macro  and  the  integer  values  represent  the 
number  of  non-terminals  being  passed  followed  by  the  number  of  attributes  affected 
(e.g.,  passio2_4-pass  in  order  to  two  non-terminals,  four  attributes).  The  arguments  for 
the  macro  follow  in  the  same  order  as  the  integer  numbers— non-terminals  first,  then 
attributes.  The  six  names  used  for  these  macros  are: 

Passup  :  Pass  up  an  attribute  from  a  child  non-terminal  ($1,  etc.)  to  the  parent 
non-terminal  ($$).  Figure  3.6  graphically  depicts  this  class. 
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Parent  Non-terminal. 


Child  Non-terminal 


Figure  3.6 

Passing  up  an  Attribute. 


Passdn  :  As  shown  in  Figure  3.7,  an  attribute  is  passed  down  from  the  parent 
non-terminal  to  child  non-terminal(s). 


Parent  Non-terminal. 

Child-T" 

Child-2  Child-3 

~~~~Child-4 

“ 1 1 

Child-n 

Figure  3.7 

Passing  Down  an  Attribute  to  "n"  Non-terminals. 


Passovr  :  Figure  3.8  shows  how  this  macro  "passes  over"  an  attribute  from 
one  non-terminal  to  another.  There  are  two  variations  of  the  passovr  macro.  The  first 
variation  is  simply  a  "passovr"  from  one  non-terminal  to  another  (passovr_l).  The 
second,  which  is  a  logical  extension  of  the  first,  passes  the  specified  number  of  attributes 
to  more  than  one  non-terminal  from  only  a  single  non-terminal.  To  vividly  display  this 
significant  difference  from  the  weave  and  passio  macros,  the  naming  of  this  variation  is 
slightly  different  from  the  standarc  -anting.  An  "x"  was  placed  between  the  first  integer 
(signifying  number  of  non-terminals)  and  the  underbar.  The  "x"  is  best  interpreted  as  a 
"times”.  Thus,  the  macro  looks  like  "passovr2x_l"  which  means  "passovr  two  times,  one 
attribute”. 


49 


Parent  Non-terminal. _ 

4 - -v  N  \ 

Child-1  Child-2  Child-3  Child-4  Child-n 

Figure  3.8 

Passing  Over  an  Attribute  to  "n"  Non-terminals. 

Passio  :  Pass  an  attribute  in  order  from  the  parent  non-terminal,  through  the 
specified  children  non-terminals  and  back  to  the  parent  Figure  3.9  shows  this  commonly 
used  macro. 

_ —  Parent  Non-terminal.  ^ _ 

fr  v  v  '  ~V\ 

Child- 1  Child-2  Child-3  Child-4  Child-n 

Figure  3.9 

Passing  an  Attribute  In  order  to  “n"  Non-terminals. 

Weave  :  Weave  an  attribute  from  a  child  non-terminal,  through  other 
specified  children  non-terminals  and  into  a  non-terminal.  As  shown  in  Figure  3.10,  this 
macro  is  similar  to  Passio,  except  the  parent  non-terminal  is  not  affected. 

Parent  Non-terminal. 

r  ^  % 

Child-1  Child-2  Child-3  Child-4  Child-n 

Figure  3.10 

Weaving  an  Attribute  to  "n"  Non-terminals. 


cat...up  :  Concatenate  ”..."  up  to  the  parent  non- terminal  from  the  children. 
The  "..."  may  be  either  the  abbreviation  "str"  meaning  string  or  "map’’  meaning  map. 
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b.  Mymac.m4. 


This  file  contains  macro  definitions  that  are  unique  to  the  type  checker.  Each 
of  these  definitions  provides  a  shorthand  method  of  expressing  multiple  lines  of  Kodiyak 
code  and  greatly  simplifies  the  readability  of  the  source.  They  can  be  logically  divided 
into  three  groups. 

(1)  Declaration  Group. 

The  declaration  group  consists  of  four  different  macros,  which  are  used  in  the 
attribute  definition  section  of  the  Kodiyak  source.  They  are  designed  to  make  each  non¬ 
terminal’s  defined  attribute  list  more  readable. 

(2)  Symbol  and  Visibility  Tables  Group. 

These  macros  are  defined  to  assist  in  the  attribute  evaluation  section  of  the 
Kodiyak  source.  They  primarily  provide  simple  statements  for  passing  the  symbol  (or 
visibility)  tables  down  from  one  non-terminal  to  another. 

(3)  Attribute  Evaluation  Group. 

This  group  of  macros  is  also  used  in  the  attribute  evaluation  section  of  the 
Kodiyak  source.  They  simplify  the  amount  of  code  used  to  express  the  equations  to 
"make  a  declaration",  etc. 

c.  Myconst.m4. 

This  M4  definition  file  contains  the  various  symbolic  constants  used 
throughout  the  Kodiyak  source.  Some  slight  variations  of  these  constants  are  also  used  in 
the  C  language  file  mylib.c  and  the  correlation  between  them  is  vital  to  the  type  checker. 
All  relationships  are  detailed  as  comments  in  the  mylib.c  file. 
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IV.  IMPLEMENTATION. 


A.  SEMANTIC  INFORMATION  STORAGE  STRUCTURES. 

To  properly  type  check  the  SPEC  source  code,  various  tables  were  required.  These 
tables  contained  information  relevant  to  each  module,  such  as  message  names, 
arguments,  parameters  and  result  types.  The  primary  requirement  that  necessitated  the 
use  of  these  tables  was  the  "non-block"  structured  nature  of  certain  SPEC  constructs.  For 
example,  when  the  information  regarding  a  specific  message  is  looked  up,  a  "match" 
must  be  searched  for  in  the  current  module  and  all  type  modules  corresponding  to  an 
argument  type  of  the  message.  These  type  modules  may  or  may  not  have  been 
previously  declared.  Another  of  the  non-block  structured  SPEC  structures  is  the  fact  that 
concept  names  are  visible  throughout  the  entire  module  in  which  they  are  enclosed,  thus 
requiring,  at  the  very  least,  that  the  module  be  "passed  over"  twice-once  to  obtain  the 
information  about  concepts,  and  the  second  time  to  type  check  the  rest  of  the  module. 

1.  Module  Types. 

The  module  types  table  contains  a  listing  of  all  the  valid  type  names  that  are 
visible  in  a  module  that  must  be  accessible  immediately  upon  entering  die  module  (e.g., 
concepts  and  module  types).  This  table  is  especially  important  due  to  the  fact  that  all 
other  tables  depend  upon  it.  Whenever  a  type  is  stored,  its  "translation"  in  this  table  is 
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used,  vice  its  actual  name.  The  translation  represents  a  globally  unique  name  for  the 
type.  This  permits  the  localizing  of  types  that  are  truly  local  to  the  module  such  as 
concepts. 

The  table  is  structured  as  a  map  from  strings  to  a  map  of  strings  to  strings.  The 
domain  string  consists  of  the  module  name,  the  domain  string  of  the  range  map 
containing  the  actual  name  of  the  type  (e.g.,  real)  and  the  range  string  containing  the 
translation  that  will  be  used  to  reference  the  type.  To  symbolize  local  names,  the  current 
module  name  is  prefixed  by  an  "<2>"  symbol  and  the  actual  local  name 
(local_name<2)  module_name) . 

One  of  the  most  important  uses  of  this  table  is  to  select  appropriate  portions  (or 
"cuts")  from  it  when  a  module  is  entered,  and  place  these  "cuts"  in  the  visible  types  table. 
This  table  is  then  used  throughout  the  module. 

2.  Symbol  Table. 

Due  to  the  lack  of  tuple  structures  in  the  Kodiyak  language,  the  symbol  table 
actually  consisted  of  five  different  tables.  Each  of  these  tables  has  a  unique  purpose. 
The  primary  table,  called  the  symbol  table,  consists  of  a  map  from  strings  to  a  map 
consisting  of  strings  to  strings.  The  primary  domain  of  the  map  contains  module  names. 
The  domain  of  the  "range  map"  consists  of  the  symbol’s  name  and  the  range  of  this  map 
contains  a  group  (or  variant  tuple)  of  patterns.  Each  pattern  is  separated  by  a  delimiter 
(PATTERN_DELIMITER). 

A  pattern  is  a  tuple  consisting  of  a  variant  sized  tuple  of  formal  or  actual 
arguments,  and  a  cross  reference  value.  Each  element  in  the  formal  or  actual  arguments 


53 


"subtuple"  is  separated  by  a  delimiter  (ELEMENT_DELEMITER)  and  this  subtuple  is 
separated  from  the  cross  reference  value  by  another  delimiter  (XREF_DELIM1TER) . 
Figure  4.1  shows  the  format  for  a  pattern  and  a  pattern  string.  In  this  Figure,  the 
ELEMENT_DELIMI'rER  is  represented  by  •,  the  XREF_DELIMITER  by  *  and  the 
PATTERN_DELIMITER  by  ♦. 

pattern 

argj*arg2*arg3» ...  •argn*xref_value 

pattern  string 

pattern  |  ♦pattem2*pattem3*  ...  pattemn 

Figure  4.1 

Example  of  a  Pattern 

The  cross  reference  value  is  of  extreme  importance  to  the  type  checker.  It  is  used 
in  the  rest  of  the  maps  which  contain  the  symbol  table  information  to  access  the 
information.  Without  this  cross  reference  value,  much  of  the  information  required  could 
not  be  accessed  properly. 

a.  Textual  Names. 

This  is  the  first  table  containing  the  symbol  table  information,  other  than  the 
actual  symbol  table.  Its  structure  is  a  map  from  integers  to  strings.  The  domain  of  the 
map  contains  the  cross  reference  value  and  the  range  contains  the  actual  text  of  the  name 
of  that  symbol.  This  information  is  commonly  used  in  error  messages. 

b.  Parameters. 

This  table  contains  the  formal  parameters  associated  with  a  symbol.  Its 
structure  is  a  map  with  a  domain  of  integers  and  a  range  of  strings.  The  domain  is  the 
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cross  reference  value  of  the  symbol  and  the  range  is  a  string  consisting  of  a  concatenation 
of  all  the  parameters  of  the  symbol  and  their  types.  Each  element  in  this  concatenation  is 
separated  by  a  delimiter  and  within  each  element,  the  element’s  name  and  its  type  are 
separated  by  a  different  delimiter. 

c.  Results. 

The  results  table  is  a  map  from  an  integer  cross  reference  value  to  a  string 
which  contains  the  result  type  of  the  symbol.  A  result  type  can  be  interpreted  in  two 
different  ways.  In  the  case  of  a  message  or  concept  with  a  VALUE  clause,  the  result  type 
contains  the  type  of  the  reply  or  value.  If  the  symbol  is  a  variable  or  variable-type 
concept,  the  result  type  contains  the  type  of  the  variable. 

Since  the  result  table  must  be  built  prior  to  its  use  in  the  actual  type 
consistency  checking,  if  the  type  to  be  placed  in  the  table  is  a  message  or  concept  call, 
the  actual  text  of  the  message  or  concept  call  is  prefixed  by  a  special  symbol,  which  I  call 
the  reference  symbol,  and  placed  in  the  range  of  the  map.  This  presents  the  requirement 
that  a  C  language  function  be  used  to  assist  in  resolving  the  type  of  any  construct,  since 
this  result  table  value  may  be  transitively  dependent  on  other  values.  This  C  language 
routine,  which  I  have  named  "Resolve_Type",  will  recursively  analyze  the  result  types  of 
different  symbols  until  a  result  type  is  found  that  is  not  preceeded  by  the  reference 
symbol. 

d.  Classes. 

This  table  is  used  to  uniquely  identify  the  classes  of  various  names.  It  is 
extremely  important  and  allows  checking  of  a  name  to  determine  if  it  is  a  message, 
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module,  concept  or  variable  name.  Each  different  class  has  a  unique  value  and  these 
values  are  detailed  in  the  file  "myconst.m4",  which  is  listed  in  Appendix  B. 

3.  Visibility  Tables. 

The  two  visibility  tables  used  by  the  type  checker  address  the  block  structured 
constructs  in  the  SPEC  language.  They  are  initially  constructed  in  a  module’s  interface 
and  then  passed  into  the  various  other  parts  of  the  module.  These  tables  are  then  added  to 
and  passed  into  additional  non-terminals  based  on  the  scoping  rules  of  the  variables  in 
SPEC. 

a.  Visible  Types. 

The  visible  types  table  is  constructed  initially  from  the  module  types  table.  In 
the  module’s  interface,  all  types  corresponding  to  the  module’s  name  are  extracted  from 
the  module  types  table  and  placed  in  the  visible  types  table.  This  table  is  then  passed  into 
all  the  other  non-terminals  in  the  program,  as  dictated  by  the  scope  rules.  The  visible 
types  table  is  not  added  to  by  concept  names  since  these  names  are  already  in  the  table. 
Any  other  types  that  are  declared  (in  variable  names)  are  added  to  the  table.  This  table  is 
used  to  build  any  table  requiring  a  type.  The  value  of  this  type  could  be  localized  or  the 
actual  name  as  discussed  above. 

b.  Visible  Names. 

The  visible  names  table  is  initially  formed  in  the  interface  section  of  a 
module.  Currently,  it  is  primarily  used  in  the  name  declaration  routines  to  determine  if  a 
name  is  already  declared.  It  will  also  be  used  extensively  in  the  type  checking  routines  to 
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obtain  the  cross  reference  value  of  a  symbol  when  that  symbol  is  used.  As  done  in  the 
visible  types  table,  it  is  passed  to  all  non-terminals  as  dictated  by  the  scoping  rules  of 
SPEC. 

B.  MAJOR  ATTRIBUTES. 

1.  Error  Reporting. 

Errors  are  reported  in  SPEC  in  one  of  two  ways.  If  the  error  can  be  identified  by 
the  attribute  grammar  equations,  a  call  to  the  C  language  function  "error_message"  is 
made.  This  function  returns  a  string  in  the  correct  format  for  an  error  message  and 
contains  the  appropriate  information.  If  the  error  cannot  be  identified  by  the  attribute 
grammar  equations,  but  can  be  identified  by  a  "C"  routine,  that  C  language  routine  may 
call  the  error_message  function  directly. 

a.  verror_message. 

The  verror_message  function  is  the  actual  C  language  function  corresponding 
to  a  call  to  "error_message"  in  the  attribute  grammar  equations.  It  is  contained  in  the 
mylib.c  file  and  detailed  in  Appendix  B.  All  of  the  codes  for  error  messages  are  a 
constant  integer  value  and  are  detailed  in  the  file  myconst.m4  and  mylib.c.  Each  error 
has  a  unique  code.  Each  code  has  a  predetermined  number  of  arguments  that  it  requires 
to  properly  report  the  error.  When  the  error  in  "invoked",  all  of  these  arguments  must  be 
passed  to  the  verror_message  function  in  the  correct  order. 

b.  Declaration  Errors . 

Declaration  errors  are  determined  by  two  different  C  language  functions-- 
"vcheck_simple_decl"  and  "vcheck_complex_decr.  The  first  of  these  routines, 
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check_simple_decl,  is  used  to  check  all  declarations  that  do  not  have  a  signature  of 
arguments  associated  with  them.  The  second  routine,  check_complex_decl,  is  used  for 
declarations  that  have  a  signature.  Each  of  these  functions  returns  a  null  string  if  the 
declaration  is  not  previously  defmed  or  an  error  message  otherwise.  All  of  the 
declaration  errors  are  placed  in  an  attribute  named  "d_error_s".  Prior  to  adding  the 
current  declaration  to  the  respective  table,  this  attribute  is  checked  and  if  it  is  NULL,  the 
attribute  is  added. 

c.  Error  Concatenation. 

All  errors  are  passed  up  the  semantic  tree  in  an  attribute  named  error_msgs_s. 
Each  non-terminal  in  the  tree  has  this  attribute  associated  with  it.  At  each  level,  the 
attributes  are  concatenated  with  the  lower  levels  and  any  errors  that  were  discovered  in 
that  level  and  passed  up  to  the  higher  levels. 

2.  Building  the  Symbol  Table. 

As  mentioned  above,  the  symbol  table  actually  consists  of  five  structures,  each 
structure  having  a  unique  purpose.  It  was  determined  that  the  four  secondary  tables 
(textual  names,  parameters,  results  and  classes)  could  be  built  independent  of  the  primary' 
table  (stbl)  since  these  tables  depend  only  on  the  cross  reference  value  which  can  be 
determined  immediately. 

The  primary  table  (stbl)  is  built  in  two  layers,  due  to  the  declaration  precedences 
of  SPEC.  These  precedences  require  that  module  names  be  globally  visible  and  unique, 
and  messages  and  concepts  be  unique  within  their  module.  Therefore,  the  first  layer  of 
the  symbol  table  building  process  collects  all  the  module  names  and  passes  them  up  to 
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the  root  non-terminal  (in  the  "ip_mxref'  attribute).  These  names  are  then  passed  back 
down  the  semantic  tree  (as  the  ip_mcmxref  attribute)  and  all  the  message  and  concept 
names  are  collected  in  accordance  with  the  scope  rules  of  SPEC.  In  this  way, 
redeclarations  are  reported  in  a  logical,  semantically  correct  order.  For  example,  if  a 
message  or  concept  name  redefines  a  module  name,  an  error  is  reported  when  the  attempt 
is  made  to  define  the  concept  or  message  name.  After  this  primary  table  is  built,  it  is 
passed  down  into  all  non-terminals  and  used  to  construct  the  visible  names  table  in  the 
interface  section  of  each  module. 

The  other  four  parts  of  the  symbol  table  are  built  in  one  layer.  This  layer  collects 
all  the  values  and  their  appropriate  range  and  passes  the  results  up  so  that  they  can  then 
be  passed  back  down  and  used  by  all  the  non-terminals. 

3.  Extended  Types. 

Due  to  the  need  to  store  result  types  in  a  result  type  table,  it  was  necessary  to 
develop  a  slightly  modified  type  called  extended  type.  If  a  type  is  immediately 
determinable,  such  as  a  literal  or  type  name,  the  range  of  the  visible_ types  table  for  the 
actual  type  name  is  placed  in  the  "xten_type"  attribute.  If  the  type  of  the  construct  is  not 
immediately  determinable,  the  actual  text  of  the  construct  is  placed  in  the  attribute.  In 
this  way,  a  C  language  function,  resolve_type,  can  take  this  value  and  resolve  the  type  of 
the  construct  or  symbol  when  needed. 

C.  NAME  ANALYSIS. 

Name  analysis  is  the  first  of  three  aspects  in  the  type  checking  process.  During  name 
analysis,  tables  are  built  reflecting  all  the  names  used  in  the  SPEC  code.  If  an  invalid 
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declaration  is  attempted  or  an  invalid  type  used,  an  error  is  reported.  The  tables  built 
during  name  analysis  are  used  during  the  second  aspect  (type  consistency  checking)  to 
determine  if  any  errors  occur. 

1.  Checking  if  an  identical  declaration  exists. 

There  are  two  routines  used  to  check  if  a  declaration  exists  prior  to  declaring  a 
name— check_complex_decl  and  check_simple_decl.  Each  of  these  routines  takes  a 
signature  and  analyzes  all  other  symbols  in  the  current  scope  to  see  if  that  name  has  been 
previously  declared.  If  it  has,  they  will  report  an  error,  otherwise,  they  return  a  NULL 
string. 

2.  Making  a  new  declaration. 

To  make  a  declaration,  three  macros  were  defined  in  the  "mymac.m4"  file.  Only 
one  of  these  macros  need  be  used.  Each  of  them  checks  a  string  type  attribute  (always 
named  d_error_s)  and  if  that  attribute  is  NULL,  makes  the  declaration.  If  the  attribute  is 
not  NULL,  meaning  that  the  declaration  would  be  a  "redeclaration",  the  declaration  is  not 
made. 

3.  Reporting  an  error. 

An  error  is  reported  at  the  declaration  point  as  detailed  in  section  1  above.  In 
each  non-terminal  atructure  that  declares  a  new  name,  the  attribute  "d_error_s"  is 
concatenated  with  all  other  error  messages  from  the  children  non-terminals  and  the  result 
is  passed  up  the  semantic  tree.  In  this  way,  the  errors  encountered  are  placed  in  the 
correct  position  within  the  list  of  error  messages. 
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D.  IDENTIFYING  ERRORS  TO  THE  USER. 

The  third  and  final  aspect  of  type  checking  reports  any  errors  that  occured  to  the  user. 
Currendy  all  errors  are  identified  by  SPEC  source  line  numbers.  Tf  no  syntax  errors 
occur,  these  error  messages  are  output  to  the  standard  output  at  the  end  of  program 
execution.  Currendy,  the  SPEC  grammar  does  not  have  syntactic  error  productions 
added  in,  although  they  have  been  developed  for  previous  versions  of  the  grammar. 
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V.  EXTENSIONS. 


A.  TYPE  CONSISTENCY  ANALYSIS. 

Type  Consistency  analysis  is  the  second  aspect  of  the  type  checking  process. 
Although  the  C  language  routines  were  coded  and  syntactically  debugged,  the  required 
attributes  have  not  been  implemented  into  the  Kodiyak  source  code. 

1.  Seeking  the  Correct  Symbol  Table  Entry. 

The  process  of  finding  the  correct  symbol  table  entry  is  similar  to  that  of  checking 
to  see  if  a  declaration  has  been  made,  except  for  the  fact  that  actual  arguments  instead  of 
formal  arguments  are  included  in  the  "source"  name.  To  obtain  the  correct  symbol  table 
entry,  a  call  is  made  to  the  C  language  routine  "seek_symbol".  This  routine  will  search 
the  current  environment  (visible_names),  and  the  global  environment  (stbl)  to  determine 
if  the  name  exists.  If  more  than  one  possible  interpretation  of  the  name  exists,  the 
function  will  return  the  appropriate  error  message,  listing  all  possible  interpretations.  If  a 
unique  candidate  exists  for  the  signature,  the  string  representation  of  the  cross  reference 
value  of  the  symbol  is  returned.  Conversely,  if  no  symbol  could  be  found  that  matches 
the  signature  passed  to  seek_symbol,  the  string  representation  of  the  integer  value  ”0” 
will  be  returned.  If  desired,  this  routine  could  be  easily  modified  to  allow  an  error 
message  to  be  returned  if  no  symbol  exists. 
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2.  Obtaining  a  Symbol  Table  entry’s  type. 

If  a  symbol  has  been  found  that  matches  the  actual  name  of  the  symbol,  another 
"C"  language  routine,  "resolve_type"  is  called  to  obtain  the  result  type  of  the  symbol. 
Using  the  information  provided  in  the  "stbl_results"  table,  this  routine  recursively 
analyzes  the  symbol’s  value  until  a  valid  type  name  is  obtained.  The  recursive  analysis  is 
required  to  resolve  this  table’s  transitive  dependency  on  other  messages  or  concepts  as 
discussed  in  Chapter  3.  When  this  transitive  dependency  is  resolved,  the  type  name’s 
translation  in  the  "visible_ types"  table  is  returned  to  the  Kodiyak  attribute.  This  attribute 
is  then  passed  up  the  semantic  tree  and  used  at  "parent  levels"  to  determine  if  an 
operation  is  valid. 

3.  Determining  if  an  Operator  is  defined. 

During  me  name  analysis,  an  entry  was  made  in  the  symbol  table  for  each 
operator  overloading.  Since  SPEC  is  entirely  defined  in  terms  of  the  standard  type 
library,  by  processing  the  standard  type  library  together  with  the  SPEC  code  to  be  type 
checked,  all  possible  operator  meanings  are  placed  in  the  symbol  table.  To  determine  if 
an  operator  use  is  valid,  simply  take  the  operator’s  textual  representation,  append  the 
appropriate  arguments  (determined  by  its  use)  to  it  and  use  the  routine  "seek_symbol”. 
This  routine  will  then  return  the  cross  reference  of  the  message  that  overloaded  that 
operator.  Then  the  result  type  may  be  obtained  as  discussed  in  section  2  above. 

4.  Reporting  Errors. 

The  reporting  of  type  checking  errors  is  very  similar  to  the  reporting  of 
declaration  errors  with  one  small  exception.  Since  "seek_symbol"  always  returns  a  string 
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value,  the  attribute  in  which  this  value  is  stored  must  be  checked  to  see  if  the  attribute 
contains  an  error  message  or  the  string  representation  of  an  integer  (greater  than  0).  If 
the  attribute  contains  an  error  message,  that  error  message  is  then  concatenated  with  the 
error  messages  generated  by  the  children  non-terminals  and  the  result  passed  up  the 
semantic  tree.  Otherwise,  only  the  error  messages  generated  by  the  children  are 
concatenated  and  passed  up  the  tree. 

B.  SPECIAL  SPEC  LANGUAGE  ISSUES. 

Some  of  the  more  complex  SPEC  issues  such  as  inheritance,  instance  declarations 
and  importation/exportation  were  addressed  and  accounted  for  in  the  design,  but  not 
implemented.  The  proposed  methods  for  implementing  these  features,  based  on  the 
design  is  discussed  below. 

1.  Inheritance  &  Instance  Declarations. 

Inheritance  and  instantiation  present  unique  challenges  to  the  generation  of  a  type 
checker  using  an  attribute  grammar  tool.  One  of  the  most  significant  problems  arises 
because  of  the  possible  transitivity  of  either  of  these  structures.  For  example,  a  module 
may  inherit  a  module  which  inherits  another  module,  which  inherits  another  module,  etc. 
This  requires  that  the  module  which  is  the  "lowest  common  denominator”  be  expanded 
first,  then  the  next,  etc. 

Additionally,  the  way  that  inheritance  is  defined  in  SPEC  poses  other  problems. 
Specifically,  if  a  module  inherits  another  module  which  contains  a  message  with  the 
same  signature  as  the  current  module,  the  two  messages  are  combined  according  to 
predetermined  rules  [Ref.  20]  to  form  the  expanded,  resultant  module. 
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a.  Preprocessor  Usage. 

To  address  these  unique  problems,  this  thesis  proposes  the  use  of  a 
preprocessor.  This  preprocessor  would  take  the  SPEC  source  code,  expand  it  as 
necessary  and  present  its  output  to  the  type  checker.  The  type  checker  would  then 
operate  upon  this  intermediate  source  code  and  produce  its  error  messages.  If  the 
"inheritance  /  instantiation  tool"  recognized  any  errors  such  as  a  circular  inheritance,  it 
would  report  these  errors  to  the  user  and  terminate. 

b.  Error  Reporting  Drawback. 

The  preprocessor  would  present  to  the  type  checker  a  modified  version  of  the 
source  code  with  no  inheritance  or  instantiation  (and  probably  write  its  output  to  a  file). 
This  however,  presents  a  problem.  Since  the  type  checker  reports  error  messages  based 
on  a  source  code  line  number,  any  errors  identified  would  be  associated  with  a  line 
number  relating  to  the  "expanded"  source,  not  the  original  SPEC  source  code. 

c.  Potential  Advantages. 

This  methodology  may  have  its  advantages,  however.  If  the  process  of 
inheritance  introduces  a  structure  that  has  semantic  errors  in  it,  the  error  could  be  looked 
up  in  the  output  of  the  inheritance  tool  and  traced  back  to  its  originator.  Also,  with  the 
advent  of  sophisticated  text  processing  tools  for  the  SPEC  language,  it  may  be  possible  to 
edit  the  "true  source”  code  in  one  window  while  viewing  the  error  in  another  window. 
Another  implicit  benefit  may  be  that  software  developers  could  use  the  inheritance  tool 
independently  to  examine  the  expanded  specification  to  determine  if  they  have  "hidden” 
or  "renamed"  everything  as  appropriate. 


2.  Importation  &  Exportation. 

One  of  the  final  issues  addressed  in  the  design  was  importation  and  exportation. 
Although  they  arc  two  different  constructs  in  SPEC,  they  are  uniquely  related--a  concept 
may  not  be  imported  unless  it  is  exported  by  the  module  in  which  it  is  defined. 
Additionally,  importation  and  exportation  do  not  present  any  of  the  problems  posed  by 
inheritance.  They  are  not  transitive  and  if  a  concept  is  already  defined  with  an  identical 
signature,  the  new  concept  cannot  be  imported  and  an  error  should  be  reported. 

The  way  in  which  the  design  was  built  presents  a  simple  solution  to 
importation/exportation.  Initially,  a  new  structure  (lclzd_exportables)  must  be  built. 
This  structure  should  be  a  localized  map  with  a  domain  of  strings  and  a  range  which  is  a 
map.  Th;s  domain  string  would  contain  the  name  of  the  module  as  in  all  localized  maps. 
The  map  which  makes  up  the  range  should  be  a  map  from  string  to  integer.  It  would 
contain  as  a  domain  the  name  of  the  concept,  and  as  a  range  an  integer  value  (0  or  1 ) 
representing  the  boolean  value  true  or  false.  The  range  would  be  true  if  the  concept  is 
exported,  false  otherwise. 

The  second  part  of  the  solution  is  when  an  importation  is  requested  by  a  module, 
this  new  table  (lclzd_exportables)  is  checked  immediately.  If  the  module  does  not  export 
the  desired  concept,  an  error  should  be  reported.  Conversely,  if  the  desired  concept  is 
exported,  the  "visible_names"  table  would  be  augmented  with  the  signature  and  cross- 
reference  information  of  the  concept(s).  This  augmentation  process  would  require  a  C 
language  function  which  processes  the  domain  of  the  "stbl"  structure  for  the  specified 
module  and  name  and  then  returns  a  string  consisting  of  all  the  new  patterns  (signature 


and  cross  reference  information)  which  are  to  be  added.  This  routine  would  have  to  be 
passed  the  "stbl_classes"  structure  so  that  it  could  verify  that  the  symbols  that  it  returns 
are  indeed  concepts  and  not  messages. 

C.  IMPROVED  ERROR  REPORTING. 

The  type  checker  currently  reports  declaration  errors  in  a  way  that  is  easy  to 
understand,  but  sometimes  difficult  to  find  the  conflicting  declaration.  In  order  to 
provide  better  feedback  to  the  user,  additional  tables  could  be  added  to  the  symbol  table 
to  promulgate  information  that  would  assist  in  error  reporting.  For  example,  a  table  with 
a  domain  containing  the  cross  reference  value  and  a  range  containing  the  line  number 
where  that  symbol  was  declared  would  enable  error  reporting  to  report  the  location  of  a 
conflicting  declaration. 

Another  error  reporting  difficulty  is  that  some  of  the  SPEC  constructs  have  WHERE 
clauses  that  require  dynamic  (run-time)  evaluation.  Although  it  is  not  feasible  to 
automatically  check  these  clauses,  it  is  recommended  that  a  warning  message  or  pragma 
be  output  listing  the  where  clause’s  contents  so  that  the  user  could  examine  this  to  ensure 
the  validity  of  the  specification. 

D.  SUBTYPES. 

Subtypes  in  SPEC  are  defined  as  concepts  and  have  a  WHERE  clause  associating  the 
concept  name  and  another  defined  type.  They  present  a  slight  problem  because,  like 
inheritance  or  instantiation,  a  subtype  may  be  transitively  dependent  on  another  subtype. 
The  solution  to  this  problem  involves  using  two  C  language  routines,  one  for  declaring  a 


subtype  and  one  for  analyzing  it  The  first  routine,  "declare_subtype"  would  take  the 
subtype  name  and  the  type  which  it  is  a  descendant  of  and  place  it  in  a  table.  The  second 
routine,  "is_subtype"  would  then  take  a  type  name  and  recursively  analyze  this  table, 
returning  a  boolean  value  representing  the  validity  of  the  subtype.  This  routine 
"is_subtype"  could  then  be  used  in  some  of  the  existing  C  language  routines  such  as 
"type_equivalent"  to  assist  in  the  determination  of  type  conflicts. 

E.  VARIABLE  ARGUMENT  OR  PARAMETER  LISTS. 

The  implementation  of  variable  argument  or  parameter  lists  (list  preceded  by  a  ’$’)  is 
an  interesting  proposition.  Since  there  are  many  diffent  ways  in  which  these  lists  may  be 
fitted  together,  a  recursive  analysis  is  required.  Currently,  variable  argument  lists  have 
been  acknowledged,  but  the  required  recurs. ,  aalysis  has  not  been  implemented.  This 
analysis  should  take  place  in  the  routines  that  check  a  declaration  and  seek  a  cross 
reference. 
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VI.  CONCLUSIONS. 


A.  INTEGRATION  INTO  A  PROGRAMMING  ENVIRONMENT. 

To  truly  provide  the  SPEC  user  with  an  effective  software  development  tool,  the  type 
checker  must  be  integrated  into  a  programming  environment.  In  addition  to  a  type 
checker,  this  environment  should  contain  at  least  a  syntax  directed  editor,  pretty  printer, 
test  case  generator  and  eventually  a  translator  that  will  translate  a  significant  part  of  the 
specification  into  a  compilable  target  language. 

In  the  short  term,  the  type  checker,  syntax  checker,  inheritance  preprocessor  and 
pretty  printer  should  be  able  to  work  together  in  a  way  that  makes  the  actual  separation  of 
these  tools  transparent  to  the  user.  This  could  be  accomplished  efficiently  by  writing  a 
unix  command  script  that  begins  a  tool  execution  when  the  previously  running  tool  (if 
any)  completes.  In  this  script,  the  syntax  checker,  inheritance  preprocessor  and  type 
checker  should  be  called  in  sequence  to  provide  the  user  with  syntactic  and  semantic 
information  concerning  their  program.  Additionally,  at  least  two  options  should  be 
provided  with  this  script.  One  option  would  allow  the  user  to  retain  a  copy  of  the  file 
containing  the  specification  after  it  has  been  expanded  by  the  inheritance  preprocessor 
and  the  other  would  run  the  pretty  printer  on  the  code  if  it  is  semantically  and 


syntactically  correct. 


B.  EVALUATION  OF  THE  TYPE  CHECKER. 

Although  the  type  checker  is  not  as  yet  a  usable  tool,  its  feasibility  has  been 
researched  and  a  solid  groundwork  has  been  laid  for  the  rest  of  the  implementation. 

1.  Kodiyak  Deficiencies. 

While  researching  this  thesis,  many  deficiencies  and  "bugs"  were  found  in 
Kodiyak.  The  primary  deficiency  was  the  lack  of  any  types  other  than  integer  and  string. 
The  implementation  of  the  type  checker  was  forced  to  use  many  identical  data  structures 
for  similar  purposes  that  should  have  been  one  structure.  Specifically,  the  symbol  table 
required  by  the  SPEC  language  necessitates  the  use  of  a  tuple  in  the  range.  Since  there  is 
no  tuple  type  in  Kodiyak,  four  maps  were  used  to  contain  the  information. 

The  inability  in  Kodiyak  to  declare  a  global  variable  also  presented  a  problem. 
Ideally,  since  the  symbol  table  is  not  modified  once  it  is  built,  it  would  be  convenient 
(and  conserve  memory  space)  if  this  table  could  be  placed  in  a  variable  or  data  structure 
that  could  be  referenced  from  every  production.  In  this  way,  fewer  attributes  would  have 
to  be  passed  down  the  semantic  tree  and  the  number  of  attribute  equations  would  be 
decreased. 

The  lack  of  documentation  in  the  Kodiyak  C  library  is  a  substantial  drawback. 
Since  Kodiyak  is  entirely  implemented  in  terms  of  other  tools,  the  handling  of  strings  and 
integers  is  defined  in  the  C  language  and  utilized  by  the  Kodiyak  processor  as  function  or 
procedure  calls.  To  effectively  extend  Kodiyak  so  that  it  could  meet  the  requirements 
dictated  by  SPEC,  many  long  hours  of  deciphering  the  source  code  and  experimenting 
was  required. 
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The  lack  of  any  predefined  Kodiyak  functions  to  output  the  contents  of  an  entire 
map  is  a  handicap.  During  the  incremental  implementation  of  the  various  maps  that 
make  up  the  symbol  table,  it  was  necessary  to  output  the  information  they  contained  to 
verify  the  functioning  of  the  attributes.  Unfortunately,  the  only  way  to  accomplish  this 
task  was  to  select  each  individual  map  entry  and  display  it.  After  a  short  while,  this 
became  very  tedious  and  so  routines  were  built  and  debugged  that  dump  one  dimensional 
maps. 

2.  Kodiyak  Benefits. 

Probably  the  most  beneficial  feature  of  Kodiyak  is  its  ability  to  preprocess  M4 
files  prior  to  conducting  the  Kodiyak  scan.  When  the  preprocessor  is  extensively  used 
and  considered  throughout  the  implementation,  the  source  code  size  can  be  shrunk 
dramatically,  making  both  the  programmer’s  and  reader’s  job  easier.  Additionally,  the 
M4  macros  defined  by  Robert  Herndon  proved  to  be  invaluable. 

Another  positive  feature  of  Kodiyak  is  the  way  it  integrates  the  functioning  of 
Lex,  Yacc  and  the  C  Compiler  to  produce  an  executable  product.  Since  all  of  these  tools 
are  reasonably  well  understood,  many  of  Kodiyak ’s  functions  can  be  analyzed  from 
another  perspective,  providing  an  alternative  approach  to  debugging. 

Kodiyak’s  C  language  interfacing  ability,  although  difficult  to  decipher  initially, 
proved  to  be  a  benefit  in  the  long  run.  It  provided  a  way  to  "work  around"  the 
deficiencies  and  implement  the  type  checker  in  an  efficient,  sensible  manner. 
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C.  FUTURE  WORK. 


1.  Extensions  of  the  current  implementation. 

The  type  checker  is  feasible  and  worthwhile  to  complete.  The  extensions  still 
required  are  implementable  by  two  students,  working  independently  and  present  no 
significant  problems.  One  student  should  focus  effort  on  the  preprocessor  and  another  on 
implementing  type  consistency  checking,  importation  and  integrating  a  current  version  of 
the  error  productions  into  the  type  checker. 

Since  the  design  and  implementation  oi  this  thesis,  the  meaning  of  a  signature  has 
been  exf<*nded  to  include  the  formal  parameters  of  modules,  concepts  and  messages.  To 
implement  this  feature,  the  type  checker’s  implementation  of  a  "pattern"  must  be 
extended  to  include  formal  parameters  by  adding  in  a  new  delimiter  and  the  additional 
information.  All  of  the  C  language  routines  which  check  declarations  and  look  up  names 
must  also  be  extended  accordingly. 

2.  Incremental  Type  Checking. 

One  significant  project  that  should  be  addressed  in  the  future  is  the  incremental 
type  checking  of  the  SPEC  grammar  within  a  syntax  directed  editor.  This  would  then 
allow  any  errors  to  be  identified  concurrently  with  the  writing  of  the  specification, 
permitting  better  time  utilization.  Additionally,  the  benefit  for  individuals  learning  the 
SPEC  language  would  be  significant  since  as  syntax  or  semantic  errors  were  made,  the 
reason  and  cause  would  be  displayed  immediately.  A  syntax  directed  editor  for  SPEC 
currently  exists  [Ref.  21]. 
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D.  GUIDELINES  FOR  EXTENDING  KODIYAK. 


The  Kodiyak  language  is  very  simple  to  extend  when  the  interactions  between  the  C 
library  and  the  actual  Kodiyak  tool  are  understood.  These  interactions  are  manifested  by 
calls  to  functions  in  the  C  library  which  are  built  through  strings  in  the  actual  Kodiyak 
AG  code.  For  example,  a  Kodiyak  language  map  reference  translates  into  a  call  to  one  of 
six  map  lookup  functions,  depending  on  the  domain  and  range  of  the  map.  Some 
guidelines  for  using  the  C  language  escape  feature  of  Kodiyak  are: 

•  Whenever  a  string  is  used  directly  from  the  Kodiyak  program,  the  string  should 
be  immediately  "flattened”  to  the  temporary  work  area  (by  means  of  a  call  to 
xtstrflatten)  and  then  IMMEDIATELY  copied  to  a  work  area  belonging  to  your 
routines.  Leaving  a  string  in  the  Kodiyak  temporary  work  area  can  be  fatal  since 
Kodiya’;  overwrites  that  w-ork  area  frequently. 

•  Always  build  in  extensive  error  checking  in  your  routines  to  avoid  errors  such  as 
array  overflow.  "Silent"  errors  in  your  routines  may  cause  other,  reportable 
errors  within  Kodiyak  which  may  confuse  the  situation. 

•  Syn tactical lv  debug  your  routines  independently  from  Kodiyak  (as  best  as 
possible)  to  avoid  unnecessary  (and  frustrating)  delays.  The  Kodiyak 
compilation  process  is  not  fast  by  any  means-especially  the  C  compilation 
phase. 

•  The  Kodiyak  program  prepends  a  "w"  to  the  name  of  a  routine  beginning  with  a 

(e.g.  a  procedure)  and  a  "v"  to  the  name  of  any  function  before  calling  that 
function  in  C. 


APPENDIX  A  -  SPEC  GRAMMAR 


This  Appendix  contains  the  version  of  the  SPEC  grammar  used  to  implement  the  type 
checker.  This  version  does  not  contain  any  of  the  syntactic  error  productions  which  have 
been  developed  or  any  attribute  definitions.  It  is  primarily  provided  as  a  quick  reference 
for  the  grammar  of  the  SPEC  language  and  for  contrast  with  the  type  checkers  attribute 
grammar  code  which  is  contained  in  Appendix  B. 


!  version  stamp  $Header:  spec.k.v  1.10  89/02/11  20:11:31  berzins  Locked  S 
!  Kopas  Version  —  Updated  to  version  1.11  of  grammar  20  April  89. 

1  In  the  grammar,  comments  go  from  a  to  the  end  of  the  line. 

!  Terminal  symbols  are  entirely  upper  case  or  enclosed  in  single  quotes  ('). 

!  Nonterminal  symbols  are  entirely  lower  case. 

!  Lexical  character  classes  start  with  a  captial  letter  and  are  enclosed  in  (). 
!  In  a  regular  expression,  x+  mea"s  one  or  more  x's. 

!  In  a  regular  expression,  x»  means  zero  or  more  x's. 

In  a  regular  expression,  [xyz]  means  x  or  y  or  z . 

!  In  a  regular  expression,  [Axyz]  means  any  character  except  x  or  y  or  z. 

I  Ir.  a  regular  expression,  [a-z]  means  any  character  between  a  and  z. 

In  a  regular  expression,  .  means  any  character  except  newline. 

!  definitions  of  lexical  classes 


%def ine 

Digit 

%def ine 

Int 

%def  ir.e 

Lette 

%def ire 

Alpha 

%aef ine 

Blank 

% define 

Quote 

%de  fine 

Backs  lash 

%def ine 

Char 

: [0-9] 

: (Digit  >  + 

: [ a-zA-Z ] 

: ((Letter) ! (Digit! I"_") 

:(  \t\n] 

:  ("] 

:"\\" 

: ( !""\\J I (Backslash ) (Quote) I (Backslash) (Backslash! ) 


definitions  of  white  space  and  comments 


: (Blank ) + 

: . »"\n" 


!  definitions  of  compound  symbols  and  keywords 


.  n  <  _  n 

:  ">  =  " 
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NE 

NLT 

NGT 

NEE 

NGE 

EQV 

NEQV 


«  *» 

n  „  <_  m 

"  —  >  =  •* 
n  tt 


RANGE 

APPEND 

MOD 

EXP 


(Backslash) IMOD 


BIND 

ARROW 


IF 

THEN 

ELSE 

IN 

U 


:  IF 
:  THEN 
;ELSE 
:  IN 
:U 


ALL 

:  ALL 

SOME 

:  SOME 

NUMBER 

: NUMBER 

SUM 

:  SUM 

PRODUCT 

: PRODUCT 

SET 

:  SET 

MAXIMUM 

; MAXIMUM 

MINIMUM 

:MINIMUM 

UNION 

:  UN  ION 

INTERSECTION 

: INTERSECTION 

SUCH 

: SUCH (Blank ) ’THAT 

ELSE_IF 

: ELSE (Blank) *IF 

AS 

:  AS 

CHOOSE 

: CHOOSE 

CONCEPT 

: CONCEPT 

DEFINITION 

: DEFINITION 

DELAY 

: DELAY 

:D0 

END 

:END 

EXCEPTION- 

:EXCEPTION 

EXPORT 

:EXPORT 

FI 

:FI 

FOREACK 

:FOREACH 

FROM 

:FROM 

FUNCTION 

: FUNCTION 

GENERATE 

: GENERATE 

HIDE 

:HIDE 

IMPORT 

: IMPORT 

INHERIT 

: INHERIT 

INITIALLY 

: INITIALLY 

INSTANCE 

: INSTANCE 

INVARIANT 

-•INVARIANT 

MACHINE 

: MACHINE 

MESSAGE 

: MESSAGE 

M  TT  ’ 

-•MODEL 

03 

:  OD 

OF 

:  OF 

OPE PAT OF 

-■OPERATOR 
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OTHERWISE 

PERIOD 

RENAME 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION 

TRANSITION 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 


lOTHERWISE 
: PERIOD 
:RENAME 
:  REPLY 
:  SEND 
: STATE 
: TEMPORAL 
:TIME 
:  TO 

:  TRANSACTION 
: TRANSITION 
:  TYPE 
: VALUE 
: VIRTUAL 
:WHEN 
: WHERE 


INTEGER_LITERAL 
RE  AL_L  I TERAL 
CHAR_LITERAL 
STRING  LITERAL 


(Int) 

( Int )" .  “  { Int ) 

HI  N  H  I  N 

(Quote  1 (Char } * (Quote  1 


NAME 


:  (Letter ) (Alpha ) * 


!  operator  precedences 
!  tleft  means  2+3*4  is  (2+3) +4. 


♦  left 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 
♦nonassoc 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 


';',  IF,  DO,  EXCEPTION,  NAME,  SEMI; 

' , ' ,  COMMA; 

SUCH; 

IFF; 

IMPLIES; 

OR; 

AND; 

NOT; 

'<',  •>' ,  '=',  le,  ge,  ne,  nlt,  ngt,  nle,  me,  eqv, 

IN,  RANGE; 

U,  APPEND; 

'+',  PLUS,  MINUS; 

'/',  MUL,  DIV,  MOD; 

UMINUS; 

EXP; 

'S',  '[',  '(',  '(',  DOT,  WHERE; 

STAR; 


♦  % 

.'attribute  declarations 


♦  ♦ 

!  productions  of  the  grammar 


start 


spec 

t  i 


NEQV 
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spec 


:  spec  module 

(  ! 

t 

!  ) 

A  production  with  nothing  after  the  "I*  means  the  empty  string 
!  is  a  legal  replacement  for  the  left  hand  aide. 


modu le 

:  function 

i  l 

t  > 

I  machine 
/  \ 

\  ) 

1  type 

/  l 

t  / 

1  definition 

i  t 

i  / 

I  instance 
{  } 

!  of  a  generic  module 


function 


machine 


concepts  END 


optior.ally_virtual  FUNCTION  interface  messages  concepts  END 

{  ) 

!  Virtual  modules  are  for  inheritance  only,  never  used  directly. 

optior.aliy_virtual  MACHINE  interface  state  messages  transactions  tempora 

•:  ) 


type 

concepts  END 


opt ional ly_virtual  TYPE  interface  model  messages  transactions  temporals 

;  l 


def  ir.it  ion 

:  DEFINITION  interface  concepts  END 

I.  i 


inst 


a  nee 


INSTANCE 
•  ) 

INSTANCE 


forr.al_r.ame  '  actual_name  END 
foreach  actual  name  END 


■  For  making  instances  or  partial  instantiations  of  generic  modules. 

■  The  foreach  clause  allows  defining  sets  of  instances. 


interface 

:  fcrm.al_r.ame  inherits  imports  export 

This  part  describes  the  static  aspects  of  a  module's  interface. 

-  The  dynamic  aspects  of  the  interface  are  described  in  the  messages. 
A  roc.-e  :s  generic  iff  it  r.as  parameters. 
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The  parameters  can  be  constrained  by  a  WHERE  clause. 

A  module  can  inherit  the  behavior  of  other  modules. 

A  module  can  import  concepts  from  other  modules. 

A  module  can  export  concepts  for  use  by  other  modules. 


inherits 

:  inherits  INHERIT  actual_name  hide  renames 

i  } 

I 

(  ) 

!  Ancestors  are  generalizations  or  simplified  views  of  a  module. 

!  A  module  inherits  all  of  the  behavior  of  its  ancestors. 

!  Hiding  a  message  or  concept  means  it  will  t  be  inherited. 

!  Inherited  components  can  be  renamed  to  avoid  naming  conflicts. 

hide 

:  HIDE  name_list 

{  ) 

I 

{  ) 

!  Useful  for  providing  limited  views  of  an  actor. 

!  Different  user  classes  may  see  different  views  of  a  system. 
Messages  and  concepts  can  be  hidden. 

renames 

:  renames  RENAME  NAME  AS  NAME 

<  ) 

I 

{  i 

!  Renaming  is  useful  for  preventing  name  conflicts  when  inheriting 
'  from  multiple  sources,  ana  for  adapting  modules  for  new  uses. 

!  The  parameters,  model  and  state  components,  messages,  exceptions, 
!  and  concepts  cf  an  actor  can  be  renamed. 

imports 

:  imports  IMPORT  name_list  FROM  actual_name 

i  i 


export 

:  EXPORT  name  list 


{  i 

messages 

:  messages  message 

{  ) 

i  ) 
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message 


:  MESSAGE  f ormal_message  operator  response 

{  ) 


response 

:  response_body 

{  } 

I  response_cases 

{  > 


response_cases 

:  WHEN  expression^! ist  response_body  response_cases 

{  } 

I  OTHERWISE  response_body 

{  ) 

respor.se_body 

:  choose  reply  sends  transition 

{  ) 

choose 

:  CHOOSE  '  ('  field_list  restriction  *)' 

{  } 


reply 

:  REPLY  aci'jal_message  where 

{  } 

GENERATE  act’jal_message  where  !  used  in  generators 


sends 

:  senes  send 


i 


:  opt  ior.a i_f  oreach  SEND  actual_message  TO  actual_name  where 

;  ; 


transit  icr. 

:  TRANSITION  expression  list 


!  for  describing  state  changes 
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formal  message 


opt icnai_except ion  opt ional_f orma l_name  forma l_arguments 

t  ) 


act ual_mes sage 

:  optional_exception  optional_actual_name  formal_arguments 

{  ) 


where 


WHERE  expression_list 


%prec  SEMI  !  must  have  a  lower 


precedence  than  WHERE 

<  ) 


opt ionally_virtual 

:  VIRTUAL 

<  ) 


(  ) 


opt ional_except ion 

:  EXCEPTION 

<  } 

i 

i  ) 


»prec  SEMI 


operator 


:  OPERATOR  opera: or_i i st 

i  ; 


opt  ior.a  If  oreach 

:  f  o  r  e  a  c  h 


f oreach 


FOREACH  '('  field_list  restriction  ’)' 

<  ) 

!  foreach  is  used  to  describe  a  set  of  messages  or  instances 


concept  s 


concepts  concept 


(  t 


concept 


INCEPT  fcr.-al_nane  '  type  spec  where 
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!  constants 

{  } 

I  CONCEPT  formal_name  f ormal_argument s  where  VALUE  formal_arguments  where 
!  functions,  defined  with  preconditions  and  postconditions 
{  ) 

model  !  data  types  have  conceptual  models  for  values 

:  MODEL  formal_arguments  invariant 

{  ) 


state  !  machines  have  conceptual  models  for  states 

:  STATE  f ormal_arguments  invariant  initially 
f  ) 


invariant  !  invariants  are  true  for  all  states  or  instances 
:  INVARIANT  expression_list 
<  ) 

initially  !  initial  conditions  are  true  only  at  the  beginning 
:  INITIALLY  expression_list 

i  ) 

transactions 

:  transactions  transaction 

i  i 

{  t 


transact  ion 

:  TRANSACTION  formal  name  '='  action_list  where 

(  1 

!  Transactions  are  atomic. 

!  The  where  clause  car.  specify  timing  constraints. 

act ion_I i s t 

:  action_list  action  %prec  SEMI  !  sequence 

i  } 

I  action 

<  } 


action 

:  action  action  Iprec  STAR  !  unordered  set  of  actions 

f  > 

!  IF  alternatives  FI  !  choice 

i  } 

!  DO  alternatives  OD  !  repeated  choice 

t  i 

1  actuai_name  !  a  normal  message  or  subtransaction 

(  ) 

'  EXCEPTION  actuai_name  !  an  exception  message 

{  ) 
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alternatives 


:  alternatives  OR  guard  action_iist 

{  ) 

I  guard  action_list 

(  > 


guard 

:  WHEN  expression  ARROW 

(  } 

I 

(  > 


temporals 

:  temporals  temporal 

<  ) 

I 

{  ) 


temporal 

:  TEMPORAL  NAME  where  response 

<  } 

f 

!  Temporal  events  are  trigged  at  absolute  times, 

!  in  terms  of  the  local  clock  of  the  actor. 

The  "where"  describes  the  triggering  conditions 
:  in  terms  of  TIME,  PERIOD,  and  DELAY. 

opt ional_formai_name 

:  forma i__name 

<  ) 

<  ) 

formai_name 

:  NAME  f ormal_parameters 

i  } 


f ormal_parameters 

!  ) 


1  parameter  values  are  determined  at  specification 
field_list  ’  )’  where 


forma i_arguments 
:  ’  (' 
<  ) 


!  arguments  are  evaluated  at  run-time 
field  list  ' ) ' 


(  > 


t  ime 
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f ield_iist 

:  field_list  field 

<  ) 

I  field 

{  ) 


field 

:  name_list  type_spec 

{  ) 

I  'S'  NAME  type_spec 

<  ) 

I  '?' 

'  ) 


type_spec 


:  actual_name 

(  ) 

I  '  ?' 

(  ) 


!  name  of  a  data  type 


name  list 


nane_list  NAME 

(  } 

NAME 

<  i 


opt  ior.a  i_actua  i_name 

:  actual  name 


actua-  name 


:  NAME  actual  parameters 


actuai_parameters  parameter  values  are  determined  at  specification  time 

:  '  • '  arc  list  '  ; ' 


%prec  SEMI  !  must  have  ?  Icwe 


;rececer.ce  tr.ar. 

;  i 


actual_argumerts  !  arguments  are  evaluated  at  run-time 

:  ' ('  arg_list  ' ) ' 


i  i 

precedence  than  '  (' 

i  ) 


%prec  SEMI  '  must  have  a  iowe 
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tprec  COMMA 


arg_iist 

:  arg_list  ' , '  arg 

<  ) 

I  arg 

<  ) 


arg 


:  expression 

(  > 

I  pair 

(  ) 


express ion_list 


expression_list  '  , 
i  \ 

,  '  expression 

%prec 

COMMA 

»  I 

expression 

%prec 

COMMA 

(  > 


:  quantifier  ’  !'  field_iist  restriction  BIND  expression  ') 

<  ) 

I  actual_name  actual_argurr,ents 

)  ) 


I  actual_name  actual_name  actuai_arguments 

<  ) 


NOT  expression 
i  \ 

tprec 

NOT 

expression 

{  } 

AND  expression 

tprec 

AND 

expression 

{  ! 

expression 

OR  expression 

%prec 

OR 

IMPLIES  expression 

tprec 

IMPLIES 

expression 

IFF  expression 

tprec 

IFF 

expression 

{  } 

'<'  expression 

%prec 

LE 

expression 

{  } 

'>'  expression 

%prec 

LE 

expression 

{  \ 

expression 

%prec 

LE 

expression 

LE  expression 

%prec 

LE 

expression 
/  \ 

GE  expression 

tprec 

LE 

i  / 

expression 
{  } 

NE  e;  .on 

tprec 

LE 

expression 

{  } 

NLT  expression 

tprec 

LE 

expression 

{  ) 

NGT  expression 

%prec 

LE 

expression 

{  ) 

NLE  expression 

tprec 

LE 

expression 

NGE  expression 

tprec 

LE 

*•  t 

expression 

EQV  expression 

tprec 

LE 

!  ) 
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%prec  LE 


expression  NEQV  expression 
{  } 


' - '  expression 

%prec 

UMINUS 

i  i 

expression  expression 

%prec 

PLUS 

\  i 

expression  expression 

Iprec 

MINUS 

X  i 

expression  expression 

Iprec 

MUL 

\  x 

expression  '/'  expression 

i  \ 

%prec 

DIV 

\  i 

expression  MOD  expression 

i  \ 

Iprec 

MOD 

1  X 

expression  EXP  expression 
/  \ 

»p  rec 

EXP 

l  X 

expression  U  expression 

%prec 

U 

expression  APPEND  expression 

/  \ 

Ipreo 

APPEND 

\  X 

expression  IN  expression 

i  \ 

%prec 

IN 

expression 

!  *x  is  the  value  of  x  in  the  previous 

l  \ 

%prec 

state 

STAP 

'  expressior. 

Iprec 

DOT 

!  $x  represents  a  collection  of  items  rather  than  just  one 
!  si  =  {x,  $s2}  means  si  =  union({x},  s2) 

!  si  =  [x,  $s2]  means  si  =  append((x},  s2) 

} 

expression  RANGE  expression  %prec  RANGE 

!  x  in  [a  .  .  b  ■  iff  x  in  {a  ..  b}  iff  a  <=  x  <*=  b 


!  [a  . .  b] 

is  sorted  in  increasing  order 

4.  f 

expression 

/  ; 

'  . '  NAME 

Iprec  DOT 

expression 

'  '  expression  '  ;  ' 

Iprec  DOT 

'  < '  expression.  '  )  ' 

'  ('  expression  NAME  ')'  !  expression  with  units  of  measurement 

:  standard  tire  units:  NANOSEC  MICROSEC  MILLISEC  SECONDS 
MINDIES  HO’JRS  DAYS  WEEKS 


TIME 
{  } 
DELAY 
*  ) 

PERIOD 


-  it era  * 

f  . 


The  current  local  time,  used  in  temporal  events 
!  The  tire  oetweer.  the  triggering  event  and  the  response 
!  The  time  between  successive  events  of  this  type 


literal  '8'  actual_r.ame  !  literal  with  explicit  type 

'?'  !  Ar  undefined  value  to  be  specified  later 

'  *'  An  undefined  and  illegal  value 

IF  expression  THEN  expression  middie_cases  ELSE  expression  FI 
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middie_cases 

:  middle_cases  ELSE_IF  expression  THEN  expression 

•;  } 

i  i 


quantifier 

:  ALL 

<  ) 

I  SOME 

(  > 

I  NUMBER 

<  ! 

I  SUM 

{  i 

I  PRODUCT 

f  ) 

I  SET 

{  i 

MAXIMUM 

t  > 

I  MINIMUM 

{  I 

I  UNION 

(  ) 

!  INTERSECTION 

1  ) 


restriction 


Iitera. 


SUCH  expression 

i  1 


:  INTEGE,'_I  ITERAL 

{  1 

RE AL_ LITERAL 
CHAR_ LITERAL 

I  } 

STR I NG_L ITERAL 

;  ’  # '  NAME 

i  ) 

■  expressions  ']’ 

t  i 

' f '  expressions  ' i ' 

f  i 

expressions  expression 

'  pair_I  ist  '  ) ' 

'  i'  Pair  '  ' 


re.a; ;cr  .itera.s  are  sets  c:  ijp.es 


!  enumeration  type  literal 
!  sequence  literal 
!  set  literal 
!  map  literal 

!  tuple  literal 
'  one  of  literal 


86 


expressions 


expression_list 

!  ! 

(  ) 


pair_list 


:  pair_list 

(  ) 

I  NAME  pair 

I  ) 

I  pair 

{  ) 


pair 


pair 


:  NAME  BIND  expression 

{  ) 


operatcr_Iis“ 

:  operator_list  operator_symbol 

<  } 

I  operator_symbol 

<  * 


ope  rat  o  r_syir.bc  1 

:  NOT 

<  ) 

!  AND 

<  ) 

OR 

f  ) 

I  IMPLIES 

<  ! 

I  IFF 
<  ) 
i  '  <’ 

; 

:  '  >• 

t  _  / 

<  ) 

LE 
(  ) 
l  GE 
i  ) 

i  NE 
(  ) 
i  NLT 
/  ; 

NGT 
<  i 
NLE 
i  } 

NG  r. 
t  ; 
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!  EQV 

1  ) 

I  NEQV 

(  ) 

I  '  +' 

(  ) 

I 

{  ) 

I  '•* 

{  ) 

I  '/' 

(  ) 

I  MOD 

(  ) 

I  EXP 

<  ) 

I  U 

(  ) 

I  APPEND 

(  ) 

I  IN 

!  ! 

I  RANGE 

{  ) 

I  ' 

{  ) 


'  r ' 


APPENDIX  B  •  CODE 


This  Appendix  contains  all  of  the  code  which  was  written  or  modified  to  implement 


the  type  checker.  There  are  eight  actual  files  contained  in  this  Appendix.  Each  file  has  a 


unique  purpose  and  the  specifics  of  their  use  is  detailed  in  the  first  file-makefile. 


1.  MAKEFILE. 

spec:  macros. m4  mylibcat.c  spec.m4 

/n  /  suns2  /us  r/  sur.s2  /  merge  /  BIN/kscript  -DAGLEXDEBUG  -DAGYACCDEBUG  \ 

-t  'tp  5000'  -t  ' %a  5000'  -t  'to  5000'  -t  'te  5000'  -s  -x  -z  -k  -e\ 

-g  -v  -d  /n/suns2/usr/suns2/merge/BIN  \ 

-DUSERLIB=\ "/n/suns2/usr/suns2/merge/kopas/thesis_imp/myl ibcat . c\"  spec .m4 


macros,  rr.4  :  lib/head.m4  1  ib/ at  t  r  ib_psg .  m4  myconst.m4  mymac.m4  lib/tail.  m4 

cat  lib/hcad.m4  i ib/at t rib_psg . m*  myconst.m4  mymac.m4  lib/tail. m4  >macros.m4 
chmod  +  r  macros. m4 

mylibcat.c:  /n  /  sur.s2 /us  r/suns2/merge /BIN/ local  lib  .  c  my  lib .  c 

cat  /n/sur.s2/usr/suns2/merge/BIN/ locailib .  c  mylib.c  >  mylibcat.c 
chmod  +r  mylibcat.c 

output:  myiib.c  lib/attrib_psg  .m,4  myconst.mt  mymac.m4  spec.m4 
print  mylib.c  myconst.m4  mymac.m4  spec.m4 
cat  1  ib/att  r ib_psg  .m.4  >  :  attrib_psg.m4 
print  attrib_psg.m4 
rm  att r ib_psg ,p4 


2.  ATTRIB  PSG.M4. 

/* 

*  Macros  for  passing  stuff  around. 

V 

define (passup_l,  'SS'.S2_s  =  Si.S2_s) 

def ine (pa ssup_2 ,  passup_i(Sl,  S2); 

passupl (Si.  S3) ) 

define (passup_3,  passup_l(Si,  S2); 

passup_i(Si,  S3); 
pasr-  -p_i  (Si,  S4  )  ) 

define (passup_4,  passup_l($l,  S 2 )  ; 

passup_l (SI,  S3 ) ; 
passup_l (SI,  S4 ) ; 
passup_i (SI ,  S  5 ) ) 
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define (passup_5,  passup_l(Sl,  S  2 ) ; 

passup_l(Sl,  S3); 
passup_l (SI.  S4 )  ; 
passjp_l (SI,  $5)  ; 
passup_l  (SI,  S 6 )  ) 

def ine (passup_6,  passup_l(Sl,  S2); 

passup_l(Sl,  S3); 
passup_l(Sl,  $4); 
passup_l($l,  S5) ; 
passup_l(Sl,  S  6 ) ; 
passup_l  (SI,  S'))  ) 

def ine (passup_7,  passup_l(Sl,  $2); 


passup_l (SI, 

S3) 

passup_l (SI, 

$4) 

passup_l (SI , 

$S) 

passup_l (SI, 

56) 

passup_l (SI, 

f  *»  * 

passup_l (Si, 

$8)  ) 

def ine (passup_8,  passup_l(Sl,  $2)  ; 


passup_l (SI, 

$3) 

passup_l (SI, 

S4 ) 

passup_l (SI, 

S5) 

passup_l (SI, 

S  6 ) 

passup_l (SI, 

S7) 

passup_I (SI, 

SO) 

passup_l (SI, 

S  9 )  ) 

def ine (passdn_l,  Sl.S2_i  =  *SS'.S2_i) 

define (passdn_2,  passd.n_l  (SI,  S2)  ; 

passdr._l  (SI,  S3)  ) 

define (passdn_3,  passdn_l(Sl,  $2); 

passdn_l (SI,  S3) ; 
passdn_i (Si,  S  4 ) ) 

def  ine  (passdn_4  ,  passdr._l  (SI,  S  2 )  ; 

passdr._l  (SI,  S3); 
passdn_l (SI,  S4) ; 
passar._l  (SI,  S 5 )  ) 

def  ine  (passdn_5,  pa  ssdr._l  ( S 1 ,  S  2 )  ; 

passdn_l (SI ,  S3); 
passdn_l($l,  S4); 
passdn_l (SI,  S  5 ) ; 
passdn_l (SI,  S  6 ) ) 

def  ine  (passdn_6,  passdn_l(Sl,  S  2 )  ; 

passdn_l  (SI,  S3) ; 
passdn_l  (SI,  S4) ; 
passdr._I  (Si,  S5)  ; 
passdn_l (SI,  S  6 ) ; 
passdr._I  (SI,  S7)  ) 

define (passdn2_l,  Sl.S3_i  =  ’SS'.S3_i; 

S2.S3  i  =  '$$'  .S3  i) 
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define (passdn2 

define  (passdr.2 


define (passdn2 


define (passdn2 


define  (passdn2 


define  (passdr, 3 


define  (passar.3 

define (passdnj 


de f  i  ne  (passdr.3 


define  ( pa  ss  dr.  3_ 

define  (passdr.4_ 
def ine (passdn4_ 
def  ine  (passdr, 5_ 

/* 

*  Passovr  is 

*  The  order  is 

*/ 

defiretpassovr 


2,  passdn2_l ( Si ,  S2,  S3); 
passan2_l(Si,  S2,  SO) 

3,  passdn.2_i  (SI,  S2,  S3); 
passdr.2_l  (Si,  S2,  SO; 
passdn2_l  (SI,  S2,  S5)) 

4,  passdr.2_l  (SI,  S2,  S3); 
passdn2_l (SI,  S2,  S4 )  ; 
passdn2_l (SI,  $2,  S5)  ; 
passdn2_l (SI,  S2,  S  6 ) ) 


5,  passdn2_l (SI,  S2,  S3)  ; 

passdn.2_i  (SI,  S2,  S 4 )  ; 
passdn2_l  (SI,  $2,  S5); 
passan2_l ($1,  S2,  S 6 ) ; 
passdn2_l (Si,  S2,  S’)) 


6,  passdn2_l (SI,  S2,  S3); 

passdn2_l  (SI,  S2,  S 4 )  ; 
passdn2_i (SI,  S2,  SS)  ; 
passdr.2_l  (SI,  S2,  $6)  ; 
passdr, 2_1  (Si,  S2,  $7); 
passdn.2_l  (Si,  S2,  S8)) 


,  Si . S4_i  -  'SS' .S4_i; 

S2 . S  4_ i  =  'SS' . S  4_i ; 

S3 . S4_i  =  ’SS '  .  S  4  i) 


) 

-  , 

passdr.3_i  (Si, 

,  S2, 

S3, 

SO  ; 

passdr.3_ 

1 (Si,  S2,  S3, 

S5)  ) 

>, 

passdn3  1  (Si, 

.  S2 , 

S3, 

SO  ; 

passdn3_ 

1 (Si,  S2 ,  S3, 

S5)  ; 

passdr.3_ 

1  (SI ,  S2,  S3, 

S  6!  ) 

1, 

passdr.3_l  (SI, 

S2 , 

S3, 

SO  ; 

passd.n3_ 

1  (SI,  S2,  S3, 

S5)  ; 

passdr.3 

i  (SI,  S2 ,  S3, 

SO  ; 

passdn3_ 

1 (SI,  S2 ,  S3, 

S7)  ) 

>  , 

passdr.3  1  (Si, 

S2, 

S3, 

S  4 )  ; 

p  a  s  s  a  r.  2 

KSi,  S  2 ,  S3, 

55)  ; 

passar.3_ 

I (SI,  S2 ,  S3, 

S  6 )  ; 

passdr.3_ 

KSi,  S2 ,  S3, 

S7)  ; 

pa  s  scr.  2_ 

KSi,  S2,  S3, 

S  8 )  ) 

. , 

passdr, 2_1  (Si, 

S2 , 

S  5 )  ; 

passdn2  1  (S3, 

S4 , 

S5)  ) 

• 

passan4  1 (Si, 

S2, 

S3, 

S  4 ,  S  5 )  ; 

passdr A  _ 

KSI,  $2,  S3, 

S  4 , 

S  6)  ) 

• 

passdr, 3  1  (Si  , 

S2, 

S3, 

S 6)  ; 

passar.2_l  ( S 4  ,  SS,  S € )  ) 


-sec  for  passing  aiiribufes  from  one  non-terminal  to  another, 
(fror, to, attribute,  .  .  .) 

S2.S3  i  =  Si  .S3  s) 


91 


aefine (passovr_2 
define  ipassov;_3 

define (passovr_4 


define  (passovr_5 


aefine (passovr  6 


passovr_l ( S 1 ,  S2,  $3)  ; 


passovr_l (SI, 

S2 , 

S4)  ) 

,  passovr_ 

1 (SI ,  S2, 

S3)  ; 

passovr__l  ($i, 

S2 

,  S4)  ; 

passovr_l ($ 1 , 

$2 

,  S  5 )  ) 

,  passovr_ 

1 (SI,  S2 , 

S3); 

passovr_l (SI, 

S2 

,  S4); 

passovr_l (SI, 

S2 

,  S5); 

passovr_l (SI, 

$2 

,  $6)) 

,  passovr_ 

1 (SI,  S2, 

S3); 

passovr_l (SI, 

S2 

,  S4 )  ; 

passovr_l (SI, 

$2 

,  SS); 

passovr_l ($1, 

S2 

,  S6); 

passovr_l (SI, 

$2 

,  S'?)) 

,  passovr_ 

1 (SI,  S2, 

S3)  ; 

passovr_l (SI, 

S2 

S4); 

passovr  1  (SI, 

$2 

SS); 

passovr_l  (SI, 

S2 

,  S6); 

passovr  1(S1, 

S2 

S7); 

passovr  1(S1, 

S2 

S  8 )  ) 

/* 

*  Pass  information  about  in  pre-order. 

*  Parent  is  first  argument,  then  children  left  to  right. 

*  Attribute  comes  last.  Macro  appends  _i  and  _s  to  attribute 

*  names  as  appropriate... 

V 


define (passioO  1, 

define (passiol  1, 

'S$'  .52  s 


define (passio2 


1, 

S2.S3_i  = 
'S3' .S3  s 


define (passic3_l. 


52 . S4_i  = 
S3 . S4_i  = 
'SS' .S4  s 


'SS' . Sl_s  =  'SS' .Sl_i) 

Sl.S2_i  =  'SS' . S2_i; 

■=  SI .  S2_s) 

S 1 . S3_i  =  'SS' .S3 _ i ; 

Sl.S3_s; 

=  S2.S3_s) 

SI . S4_i  =  'SS' .S<_i; 

51 .  S‘)_s ; 

52 .  $4_s; 

=  S3  .  S<  s) 


define (passio0_2,  passioO_l  (SI)  ; 

passioC_l ( S  2 ) ) 

define (passioC_3,  passioO_l (SI) ; 

passioO_l  (S2) ; 
passioC_l  (S3) ) 

define!  pa ssio0_4,  passioO_l(Sl); 

passioO_l  { S 2 ) ; 
passioO_l (S3) ; 
passioC_l ( S4 ) ) 
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define (passioC 


define (passiol 


define (passiol 


define (passiol 


define (passiol 


define (passio2 


define  (passic2 


define (passio2 


define (passio2 


de f ine  (passiol 


def ine (pass  io3 


def ine  (passiol 


6,  pass ioC_i ( $  1 ) ; 

passioC_l  ($2 ) ; 
pass ioC_l  ( S3 ) ; 
pass i cO_l ( S  4 ) ; 
passioO_l ( S  5 ) ; 
passioO_l (S6)  ) 


2,  passiol_l  (SI,  $2)  ; 

passiol_l (SI,  S3) ) 

3,  passiol_l  (SI,  S2)  ; 

passiol_l  (SI,  S3); 
passiol_l (SI,  $4) ) 

4,  passiol_l (SI,  52); 

passiol_l (SI,  S3); 
passiol_l (SI,  S4); 
passiol_l ($1,  S  5 ) ) 

5,  pass  ol_l(Sl,  S2) ; 

passiol_l (SI,  S3) ; 
passiol_l  (SI,  S4) ; 
passiol_l (SI,  S 5 )  ; 
passiol_l (SI,  S  6 )  ) 


2,  passio2_l (SI,  S2,  S3); 
passio2_l (SI,  S2,  S4 ) ) 

3,  passio2_l (SI,  S2,  S3); 
passio2_l (SI,  S2 ,  S 4  )  ; 
passio2_l (SI,  $2 ,  S5) ) 

4,  passio2_l  (SI,  S2,  S3); 
passio2_l  (Si,  S2,  S4»; 
passio2_l  (SI,  $2 ,  S 5 )  ; 
passio2_i (SI,  52,  S6) ) 

5,  passio2_l (SI,  S2,  S3); 


pass  ic2 

1  (Si, 

S2, 

S4)  ; 

passic2 

1  (Si, 

52, 

$5) 

passic2 

1  (Si, 

52, 

5  € ) 

passio2 

i  (Si, 

52, 

5  7 )  ) 

2,  passio3_l (SI,  S2,  S3,  S4) 

passio3_l  (SI,  S2,  S3,  S 5 ) ) 


3,  passio3_i  (SI,  S2,  S3,  S4) 

passio3_l (Si,  S2,  S3,  55); 
passio3_l (Si,  52,  S3,  S 6 )  > 


pass! 

c3_l  (Si, 

S2, 

pasi.  i  o3 

.1  (Si, 

S2, 

S3, 

S  5 )  ; 

pass io3 

1  (Si, 

S2, 

S3, 

S  6 )  ; 

pass :c 3 

i  (  S  1 , 

S2 , 

S3, 

S7)  ) 

S4 ) 
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5, 

passi 

o3  1 

(SI, 

52 , 

passio3_ 

1  (SI, 

S2, 

S3, 

S5> 

passio3_ 

.1 (SI, 

S2, 

S3, 

56) 

pass io3_ 

i  (SI, 

$2 , 

S3, 

S7) 

passio3_ 

1  (SI, 

S2, 

S3, 

S  8 ) 

/*  pass  up  strings, 
define (catstrup2_l, 
define  (catstrup3_l. 


concatenated  together 
'$$' . $3_s  =  SI . S3_s 
'SS'  .$4  s  -  $1.54  s 


/ 

S2.$3_s) 

$2. $4  s  *  $3. $4  si 


/*  pass  up  maps,  concatenated  together  */ 


define (catmapup2_l. 

'$$'  . $3_s  =  $  1 . $3_s 

+  1 

52.53 

define (catmapup3_l, 
define (passovr2x_l. 

'$$' . $4_s  *  $1 . $4_s 
passovr_l ($1,  $2,  $4)  ; 
passovr__l  (51,  $3,  54)  ) 

+  1 

S2.S4 

define (passovr3x_l. 

passovr2x__l  (51,52,53,55) 
passovr  1(51,54,55)) 

• 

define (passovr4x_l , 

define (passovr2x_2, 

passovr2x_l (51,52,53,56); 
pa**sovr2x_l  (51,54,55,56)) 
passovr  2(51,52,54,55); 
passovr  2(51,53,54,55)) 

define (passovr3x_2. 

passovr3x_l ($1 ,  $2,  $3, 

54, 

S5)  ; 

passovr3x_l (SI,  S2,  S3, 

54, 

S6)  ) 

define <passovr4x_2, 

,  passovr4x_l (SI,  S2,  S3, 

S4, 

SS, 

passovr4x_l (5 1 ,  S2,  S3, 

S4, 

SS, 

s) 

s  +  I 


$6)  ; 
$7)  ) 


53.54  s) 


weave  --  a 


def ine (weave 3 


define (weave4  2, 


$3  .  S5_i 
54 .S5_i 
’SS' . S5 

def me (passio4_2,  passio4 


rtial  ve 

rsion  of 

passi 

o . 

s  assume 

s  the  fir 

st  no 

nterrr.ina 

i  generates  the  attribuf 

ill  non- 

termina  i  s 

list 

ed  u 

se  t 

he  product  of  the  previc 

irminal , 

but  the 

attribute 

is 

not  returned  to  the  pare: 

►rrr.inal 

after  it' 

s  use 

by 

the 

last  nonterminal. 

passovr 

(Si, S2, 54 

) ; 

passovr 

($2, S3, S  4 

)  ) 

weave 3 

1 (SI,  S2 , 

S3, 

SS)  ; 

passovr 

(S3,  S4, 

55)  ) 

wea ve3_ 

1  (SI,  $2, 

S3, 

54)  ; 

wea ve3 

1(51,  S2, 

S3, 

55)  ) 

weave 4 _ 

1(51,  52, 

S3, 

54, 

55)  ; 

weave4_ 

1(51,  52, 

S3, 

54, 

56)  ) 

51  .S5_ 

i  =  ’SS'  . 

$5_i; 

52.55 

i  =  SI. 55 

s ; 

=  S2.S5_s; 

=  S3 . $5_s; 
s  -  S4.S5_s) 

1 (Si,  S2,  S3,  $4,  551  ; 
passio4  1(S1,  S2,  S3,  $4,  S6) ) 


94 


def ire  (passic5_ 

i 

SI . $6_i 

= 

'SS' . S6_i ; 

S2.S6_i 

SI . S6_s; 

S3 ,S6_i 

S2.S6_s; 

$4 .S6_i 

S3 . S6_s; 

S5.S6_i 

= 

S4  . 5  6_s ; 

'SS'  .  S6_ 

s 

=  S5.S6_s> 

define  <passio5_ 

2, 

passioS_ 

(SI,  $2,  S3, 

S4 , 

SS, 

S6) ; 

passio5_ 

(SI,  S2,  S3, 

$4 , 

SS. 

$71  ) 

define  (passio6_ 

X  , 

$l.$7_i" 

= 

'SS'  . S7_i; 

S2.S7  i 

- 

Sl.S7_s; 

S3 . S  7_i 

= 

S2.S7_s; 

S4.S7_i 

= 

S3 . S7_s; 

S5.$7_i 

= 

S4.S7_s; 

$6 . $7_i 

= 

SS.S7_s; 

'SS'  .  S7_ 

s 

=  S6.S7_s) 

define  (passio6 

2, 

passio6_ 

1 

(Si,  S2,  S3, 

S4, 

55 , 

S6,  $7)  ; 

passio6_ 

1 

(SI,  $2 ,  S3, 

S4, 

SS, 

S  6,  58)  1 

3.  MYMAC.M4. 


/*  Macros  used  for  making  declarations  snorter. 


V 

define  < I?_S?3L_IN? 0, 
ip_stbl_names_s 
ip_stb-._parax.s_s 
ip_stbl_resuit_s 
ip_stbi_ciass_i 
ip_stbl_names_i 
ip_stbi_parax.s_i 
ip_stbl_result_i 


ip_stbl_class_s  :  int->int; 
int->st ring; 
int->string; 
int->st r ing; 
int->int ; 
int->st ring ; 
ir.t->st  ring; 
int->st r ing) 


define  <ST3L_INFC, 
stt>I_ciass_i 
st bl_names_i 
stbl_params_i 
stbl  result  i 


stbl_i  :  st ring->st r ing->st ring; 
int->int ; 
ir,t->  string; 
mt->  string; 
ir,t->st  ring) 


define ( VIS IBILITY_T3LS ,  vi s ible_t ypes_i 


vis ib.e_ type s_s  :  st r ir.g->st r ing; 
vi 5 ibie_r.axes_ i  :  st r ing->st r *ng ; 
vi s ibienaxess  :  string->st ring) 


st ring->st  ring; 


define  ( 1 ?_MCMXR£F_73LS ,  ip_mcmxref_s  :  st r ing->str ing; 

ip_mcxucref_i  :  st  r  ina->st  r  ing) 


/* 

*  Macro's  used  for  various  tasks  including  defining  names,  etc. 

*  mx_sirrpie  6  x.k_cox.plex  are  very  much  alike.  mk_complex  has  arguments  ($5) 

*  though. 
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def  ine  (mk_simpie_decl_io,  $l_s  =  (S2  ==  NULL_STRING) 

->  ( S i _ i  (S3)  ■=«  NULL_STRING) 

->  {(S3  :  [XREF_DELIMITER,  i2s (S4 ) ] )  }  +1  S 1_ i 
'  {  (S3  :  (XREF_DEL:m:TER,  i2s ($4) , 

PATTERN_DELIMITER,  Sl_i  (S3)]))  *l  Sl_i 

S 1 _ i ) 

def ine (mk_simple_decl,  $5  -  ($2  —  NULL_STRING) 

->  (SI  (S3)  —  NULL_STRING) 

->  {(S3  :  (XR£F_DELIMITER,  12s  (S4)]))  +1  SI 
'#'{(53  :  (XR£F_DELIMITER,  i2s(S4), 

PATTERN_DELIMITER,  SI  (S3)]))  +1  SI 

'#'  SI) 

def ine (mk_complex_deci ,  Sl_s  ”  (S2  »“  NULL_STRING) 

->  (SI _ i  (S3)  —  NULL_STRING) 

->  ((S3  :  | S  5 ,  XR£F_DELIMITER,  i2s(S4)]))  +1  Sl_i 
' # '  { (S3  :  (Sl_i  (S3),  PATTERN_DELIMITER,  S5, 

XREF_DE LIMITER,  i2s(S4)]))  +1  Sl_i 

'#'  3 l_i ) 

define (add  ele.n,  S4  -  SI  *  { <S2  :  S3))  ) 


/  * 

*  Macro's  used  for  passing  around  the  symbol  table  information. 

*  This  is  the  stuff  that  never  changes,  e.g.  is  not  modified  during  progress 
’  of  type  checking  a  module. 

*  Symbol  Table  Information  Consists  of 

*  1 .  stbi 

*  2.  stbl_nam.es 

*  3.  stbi_resuit 

*  4.  stbi_ciass 

*  5.  stbl_params 

V 


/"  symbol  table  building  macros  */ 

def  ine  ( stbl_bui  idC ,  passio0_4  (ip_stbl_class,  ip_stbl_names,  ip_stbi_pa'-ams, 

ip_stbl_result ) ) 

aefme  ( st bl_bu i Idl ,  passiol_4  (SI,  ip_stbl_class,  ip_stbl_names,  ip_stbi_params , 

ip_stbl_result ) ) 

define (stbl_ouild2,  passio2_4(Sl,S2,ip_stbl_class,ip_stbI_names, 

ip_stbi_pa rams,  ip_stbl_re su It ) ) 

define ( st b l_bu i 1 d  3 ,  passio3_4(Si,S2,S3,ip_stbl_class, ip_stbl_names , 

ip_stbl_params,  ip_stbl_resuit ) ) 

define (stbi  build4,  passio4_2(Si,S2.S3,S4,ip_stbl_class,ip_stbl_names); 

passio4_2(Sl,S2,S3,S4, ip_stbl_params,  ip_sib»_result) ) 
define ( st bl_bu i id5 ,  passio5_2(SI,S2,S3,S4,S5,ip_stbl_cIass, ip_stbl_names) ; 

passio5_2 (S1,$2,S3,S4,S5, ip_stbl_params,  ip_stbl_result) ) 
define (stbl_build6,  passio6_2 (SI, S2, S3, S4, $5, Sfi, ip_stbl_class, ip_stbl_names) ; 

passio6_2 (S1,S2,S3,S4,S5,S6, ip_stbl_params.  ip_stbl_result) ) 

def ine (passdn_stbil ,  passdn_5($l,  stbi,  stbi  result,  stbl_class,  stbl_names, 

stbl_params) 1 

def ine (pa ssdr_s t b  12 ,  pa ssdn2_5  ( S 1 ,  S2,  stbi,  stbl_result,  stbl_ciass,  stbl_names, 

stbi_params ) ) 

def  ine  (passdn_stb!3,  passdn.3_5  (SI,  S2,  S3,  stbi,  stbl_result,  stbl_class, 

stbl_names, stbl_params) ) 
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aef  me  {passer.  s*r>14,  passar.3_5  ( $  1 ,  S2,  S3,  stbl,  stbl_result ,  stbl  class 

st  bl_names, stbl_pa  rams) ; 

passdr._5  ($4,  stbl,  stbl^resul t,  stbl_class, 
stbl_r.ames,  stbl_params)  ) 

defm-.  lpassar_st.fcl5,  passdr.3_5  ( SI ,  S2,  S3,  stbl,  stbl_result,  stbl  class 

stbi_names, stbl_params) ; 

passar.2_5  ($4 ,  $5,  stbl,  stbl_result,  stbl__class, 
stbi_names,  stbl_params)  ) 

def ine (passdn_stbl 6,  passdn3_5 ($1,  $2,  $3,  stbl,  atbl_result,  stbl_class 

stbl_names, stbl_params) ; 

passdn3_5  ( 5 4 ,  $5,  $6,  stbl,  stbl_reault,  stbl  class 
stbl_names, stbl_params) ) 


4.  MYC0NST.M4. 


/*  Symbolic  Constants  used  in  Program  —  Are  always  capitalized.  */ 
define  (NL'LL_STR:NG,  '"■•) 

def  ine  (L'NDEFINEO_TYPE,  '"Type  Name  Undefined."’) 

define  (S?EC_L:3RARY_M0:>’JLE_type,  '"type”  ) 

define !  GLOB AL_TYPE_N AMES,  ’"#giobail” ) 

define (CURREN7_MC0ULE_TAS,  ' " #cur rent  module#" ’ ) 

aef  ine  (FALSE,  C  ) 

define  (FUNCTION_CLASS,  1) 

define (MACK:NE_CLASS,  2) 

aef ine (TYPE_CLASS,  3) 

define  (def:n:t:on__class,  <) 

define  CNSTANCF_CLASS,  51 
define (MESSAGE_CLASS ,  6) 
define (CCNCEr 7_CLASS i ,  7) 
define (CONCE?7_CLASS2 ,  8) 
define (VAR:aBLE_CLASS,  9) 
aef  ine  (TRANSAC7:0N_CLASS,  ZZl 
define (TEM?ORAL_CLASS,  11) 
define !?A77ERN_CELIMI7ER,  '"*"’ ) 
define (XREF_DEL.X:TER, 
aef  ine  (ELE.M_GELIMI7ER, 
define (REF_SYM30L,  '"*”) 
aef  me  (A77LA-_0ELTM, 
de  f  me  (?a:?_GEL:m, 


*  Errors  i  Warning  Messages  Generatea  by  Koaiyak  code. 

de f i ne (LNRESCLVE7_7Y?E,  -1) 
define  (UNLEC LABEL _  TYPE ,  3) 
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5.  HEAE.ivI4 


divert  ( -1 ) 

/* 


*/ 


Copyright.  1986,  Robert  Herndon 
(C)  1986,  Robert  Herndon 
Modified  by  Robert  Kopas  1989. 

Purpose  -  To  allow  Consistency  and 
for  the  type  checker. 


implement  macros  needed 


6.  TAIL.M4. 

/* 

*  Many  of  mVs  keywords  are  commonly  used  words.  Remove 

*  all  buil^in  macro  names  tc  suppress  ar.y  unexpected  side-effects. 

*/ 

undefine (  ' t ' ) 
undefi.ne  (  ' changequote ’  ) 
undefine (  'define' ) 
undefine ( 'divnum' ) 
unde f  ine  (  'dr.  1 '  ) 
undefine (  'dumpdef ' ) 
undefine (  'errprint' ) 
undefine ( *e va 1 ' ) 
undefine (  •  i fdef ' ) 
undefine  (  ’ifelse' ) 
undefine ( 'include' ) 
undef  ir.e  (  *  incr'  ) 
undefine (  'index' ) 
undefine ( 'ien' ) 
undefine ( 'maketemp' ) 
n"def ine ( 's include' ) 
unde  fine!  'substr' ) 
undefine ( 'syscmd' ) 
undefine ('translit') 
undef  ir.e  (  'undivert '  ) 
divert ( C ) 

undefine ( 'divert' ) 
undef ine ( 'undefine'  ) 


7.  MYLIB.C. 


/'  Symbolic  Constant  Declarations 


these  concur  with  those 

*/ 

def ined 

#de  fine 

KYCHARLENMAX 

100CC 

#de  fine 

MAX_XR£F_NUM_LEN 

20 

#de  fine 

PATTERN_DE LIMITER 

•  *  • 

#def ine 

XREF_DE LIMITER 

t  _  t 

♦aef ine 

ELEM_DE LIMITER 

' ; ' 

♦define 

END_ELEMENT ( s ) 

(*s  == 

♦define 

END_ACTUALS ( s ) 

(*s  «= 

#def ine 

END_FORMALS (s) 

(*s  == 

Mae f i ne 

END  PATTERN (s) 

(*s  =  = 

-  It  is  extremely  important  tha 
in  mymac.m4 


ELEM_DELIMITER) 

'  \0’  ) 

XREF_DELI'1ITER) 
PATTERN  DELIMITER) 


♦define  UNDEFINED_TYPE  "Type  Name  Undefined." 

♦  define  C'JRRENT_MCDL'LE_TAG  "♦current_noduiet" 

♦define  MESSAGE_CLASS  6 

/*  errors  --  those  that  are  enumerated  in  mymac.m4  must  concur  with  these 
also . 

V 

♦define  NAME_REDEFINED  1 

♦define  CNAME_REDEFINED  2 

♦define  UNDECLAR£D_TYPE  3 

♦define  NONSPECIFIC_R£FERENCE  A 

/* 

*  Warning  Messages 

*/ 

♦define  UNRESOLVED  TYPE  -i 


int  last_xref  =  0; 

/’ 

’  v_get_new_xre f  has  an  argument  named  unused  just  to 
*  satisfy  Kodiyak  syntactic  requirements. 

’  Everytime  the  routine  is  called,  it  will  obtain  a  new,  unique  xref. 

*/ 

int  vget_new_xref (  unused  ) 
char  ’unused; 

{ 

return  (-*iast_xref) ; 

! 

char  mychars [MYCHASLENMAX; ; 
int  mycharler.  -  C; 

wxrefs_dump  (xreftostrmap) 
xobject  xreftostrmap; 

< 

int  cur_index; 
xstrin.g  lookup_elem; 

for  (cur_index  =  1;  cur_index  <=  last_xref;  cur_index++)  { 
iookup_eiem  =  xinapslkup (xreftostrmap,  cur_index)  ; 
prir.tf  ("\t%d  :  ”,  cur_index)  ; 
woutput (icokup_eler) ; 
prir.tf  ( " \ r. " )  ; 
ff iush (staout) ; 

) 


wxref i 
xob jec 

f 

int 
int 

for  (eur_indf  ;  cur_index  <  =  iast_xref;  cur_index++)  ( 
loo  ;p_eit'  x imapi 1 kup ( xre f to intmap,  cur_index); 

prir. ;  f  i  ”  \  t  *d  :  %c\n",  cur_index,  lookup_e]e.m)  ; 

ffl  ,sf.  (staout)  ; 


_dump  (xreftointmap) 
t  xrefto’  map; 

cur  , 

lookt 
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i 

) 

wsmapi_dump(  mapname) 
xobject  mapname; 

( 

struct  xmflatten  f; 
xobject  p; 
int  defval; 
int  defined; 
int  range_val; 

if  ( (XHEAP (mapname)  tt  ! XPAIR (mapname)  )  ( 

xerr  ("smapi_dump  —  Non  Map  Argument  \n",  0,  0,  0) ; 

) 

defined  =  XFALSE; 

defval  =  0; 

xminit  (tf,  mapname) ; 

for  (p  -  xmnext(tf);  p.op_type;  p  -  xmnext(tf)  )  ( 

if  (! XPAIR (p) ) 

xerr ("smapi_dump  —  Corrupt  map.  \n",  0,0,0); 
if  (p.op_type [0] .op_type)  ( 

range_val  =  * (p. op_type [ 1 ] . ip_type ) ; 

printf("\t  %s  ->  td\n”,  xt serf latten (p . op_type ( 0] ) , range_val ) ; 
fflush  (stdout); 

} 

else  if  ((defined)  ( 

defval  =  * (p . op_type [ 1 j . ip_type) ; 
defined  =  XTRUE; 

) 

}  /*  end  for  loop  •/ 

printf("\t  DEFAULT  ->  %d\n",  defval); 

fflush (stdout) ; 

> 

wsmaps_dur.p  (  mapname) 
xobject  mapname; 

{ 

struct  xmflatten  f; 
xobject  p; 
xobject  defval; 
int  defined; 
xheap  range_val; 

if  (! XHEAP (mapname )  li  ! XPAIR (mapname )  )  ( 

xerr  ("smapi_dump  --  Non  Map  Argument  \n",  C,  0,  0); 

) 

defined  =  XFALSE; 

de f va 1 . op_t ype  =  (xheap!  0; 

xminit  (tf,  mapname) ; 

for  (p  ■■  xmnext(tf);  p.op_type;  p  ■=  xmnext  (tf)  )  ! 
if  ( !  XPAIR  (p)  ) 

xerr ("smaps_dump  —  Corrupt  map.  \n",C,0,0); 
if  (p  op_type [0] .op_type)  ( 

range_val  =  p . op_type [ 1 ] . op_type ; 

prir.tfCVt  %s  ->  ”,  xtstrfiatten(p.op_type(C!)); 

xheapprint (stdout ,  range_val); 
printf  On")  ; 
fflush  (stdout )  ; 

) 

else  if  (  def  in.ed)  I 
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ciefvai  ■=  p .  op_t  ype  \ I  j  ; 
defined  =  XTR'JE; 

) 

!  /*  end  for  loop  */ 

printf  ("NtDEFA'JL?  ->  *>; 

xheapprint (stdout,  defval); 
printf  C\n")  ; 
f flush (stdout ) ; 


/* 

*  copy_pattern  --  designed  to  copy  a  specific  pattern  to  a  destination 

*  address.  It  returns  the  length  of  the  pattern  copied  or  0. 

*  if  the  pattern  is  a  null  string  (or  equivalent),  a  ' \0‘  is  copied. 

V 

int  copy_pattern  (d_addr,  s_addr,  max_len) 
char  *d_addr,  *s_addr; 
int  max_len; 

{ 

int  char_cnt  «  C; 

for  (;((*s_addr  !•=  PATTERN_DELIMITER)  it  (*s_addr  !=  '  \ 0 '  )  it  (max_len  >  0)  ) 
;  s_addr+»,  d_addr*^,  max_len — ,  char_cnt++) 

*d_addr  =  ’s_adar; 
if  (max_len  >  C)  { 

*d_addr  =  'Non¬ 
return  (char_cnt  +  1);  /*  include  'NO'  */ 

) 

return  (max_ler.)  ; 

I 


char  *verror_message  (err_r.uiti,  line_no,  xa,  xb,  xc,  xd  ) 

int  err_num; 

int  line_r.o; 

xobject  xa,  xb,  xc,  xd; 

{ 


case  NAME_REDEFINED: 

return  vfrr.t  ("***  ERROR  ***  Line  Id  :  Name  Already  Defined  --  %s 
(by  item  Is )  Nr." , 
iine_no,  xa,  xb) ; 

break; 

case  CNAME_REDEF INED : 

return  vfmtC***  ERROR  ***  Line  Id  :  Name  Already  Defined  —  Is  (Is) 

(by  item  %s)Nn", 
line_no,  xa,  xb,  xc) ; 

break; 

case  UNDECLARED_TYPE: 

return  vfmt ("***  ERROR  ***  Line  Id  :  Type  Name  Undeclared  —  tsNn", 
line_no,  xa) ; 

break ; 

case  NONSPECIFIC_REFERENCE : 

return  vfir.t  (”*’*  ERROR  ***  Line  Id  :  Do  you  mean  4sNr.”,  line_no,  xa); 
case  UNRESOLVED_TYPE ; 

return  vfntP**  WARNING  **  Line  Id  :  Unresolved  type  usedNn",  line_no) 
break; 
default: 
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break ; 


) 

return 


♦define 

more_sig_patterns (s) 

<*3 

!-  '\0') 

♦define 

next_pattern (s) 

for 

(;*s  !-  '  \0*  ; )  \ 

if  (*s++  —  P ATTERN_DELIMI TER ) 

\ 

break 

♦define 

next_element (s) 

for 

(  ;  (  ( *  s  !-  '  \0 '  )  U  (*s  !-  XR£F_ 

DELIMITER) ) ;] 

1  \ 

if  (*s++  --  ELEM_DELIMITER>  \ 
break 

int  num_copied  «  0; 

♦define  cp2mychars (s)  if  ( (num_copied  -  copy_pattern  Umychars  [mycharlen]  ,  \ 

s,  MYCHARLENMAX  -  mycharlen)) )  \ 
mycharlen  »  mycharlen  +  num_copied;  \ 
else  \ 

xerr ("MYCHARLENMAX  exceeded  —  increase 


MYCHARLENMAX.",  \ 


0,0,0) 


/* 

’  Name  declaration  routines. 

*  These  routines  check  for  the  existence  of  a  signature. 

*  If  the  signature  exists,  they  return  an  error  message  stating  that 

*  the  signature  cannot  be  redefined.  Otherwise  they  return  "" 

*/ 


xstring  vcheck_simple_decl  (name_map,  name,  line_no,  xref2name_map) 

xobject  name_map,  name; 

int  line_no; 

xobject  xref 2name_map; 

< 

char  xref_number  (MAX_XREF_NUM_LEN] ; 
char  "patterns; 
char  *tmp_args; 

patterns  =  xtstrflatten  (xsmapslkup (name_map,  name)); 
while  more_sig_patterns (patterns)  { 

if  (‘patterns  ==  XREF_DELIMI TER)  (  /*  empty  pattern  —  no  args  */ 

for  (tmp_args  =  patterns;  *tmp_args++  !*  XREF_DELIMITER;  ) 

if  (copy_pattern (xre f_number ,  tmp_args,  MAX_XREF_NUK_LEN) ) 

return  (xstring)  verror_message (NAME_REDEFINED,  line_no,  name,  ximapslkupl 
xref2name_map,  atoi (xref_number) ) ) ; 

else 

xerr ("Exceeded  MAX  XREF  NUM  LEN  —  Increase  value ...*,0,0,0); 


else 

next_pattern (patterns)  ; 

) 

return  (xstring) 
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xstring  vcheck_complex_aecl  (name_map,  name ,  f_args,  line_no,  xref 2name_map) 

xobject  name_map,  name,  f_args; 

int  line_no; 

xobject  xref 2name_map; 

( 

char  ’patterns; 
char  »new_sig; 

char  xref_number [MAX_XREF_NUM_LEN] ; 
char  *tmp_name,  *tmp_args; 
int  retval; 

mycharlen  -  0; 

new_sig  *  mychars; 

cp2my  chars  (xtstrf  latter,!  f_args)  )  ; 

patterns  =  xtstrf  latter,  (xsmapslkup  (name_map,  name)); 
while  more_sig_patterns  (patterns)  ( 

if  (match_f_fp  (new_sig,  patterns) )  ( 

for  (tmp_args  =  patterns;  *tmp_args++  !*>  XR£F_DELIMITER;  ) 

if  (copy_pattern (xref_number,  tmp_args,  MAX_XREF_NUM_LEN) )  f 
trep_r.ame  -  Smychars [mycharlen] ; 
cp2raychars (xtstrflatten (name) ) ; 

/*  remove  xref  value  and  delimiter  from  args.  */ 

for  (tmp_args  =  new_sig; ( ( *tmp_args  !=  XREF_DELIMITER)  SS 

<*tmp_args  !=  '\0'))  ;) 

tmp_args**; 

*tmp_args  =  ' \0' ; 

return  (xstring)  verror_message (CNAME_REDEFINED,  line_no,  name,  new_sig, 
ximapslkup (xref2name_map,  atoi (xref_number ) ) ) ; 

i 

else 

xerr ( "Exceeded  MAX_XREF_NUM_LEN  --  Increase  value C, 0, 0) ; 

! 

else  ( 

r.ext_patterr.  (patterns)  ; 

} 

)  /*  end  while  ’/ 
return  (xstring) 

) 


/*  type  equal  is  strict  equality.  No  allowances  are  made  (or  should  be! 

for  subtypes  cr  equivalences.  */ 
int  type_equal  (argl,  arg2) 
char  ’argl,  ’arg2; 

( 

/’  position  both  args  at  beginning  of  type.  */ 
while  ( ’argl -+  :  =  ’  : ' ) 

while  (*arg2--  !=  ':') 


for  (;  ’argl  ==  ’arg2;  argl-’,  arg2--l 

if  ((’argl  ==  ELEy_DELIKlTER)  II  (’argl  -=  XREF_DELIMITER) ) 
return  ( 1 ) ; 

/’  an  exception  ccr.drticn.  ’/ 

if  ((’argl  ==  ' \C ' )  St  (*arg2  ==  XREF_DELIKITER!  ) 
return ( 1 ) ; 
return  (!)  ; 
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int  match_f_fp  (temp_new,  temp_old) 
char  *temp_new,  *temp_old; 

( 

while  ( ( *temp_new  !■=  '\0')  It  (*temp_old  !■  XREF_DELIMITER) )  { 

if  (type_equal  (temp_new,  temp_old)  )  { 

if  ((*temp_new  —  '$')  tt  (*temp_old  —'$'))  ( 

next_element (temp_new) ; 
next_element (temp_old) ; 
l 

else  if  (*temp_new  'S')  < 

/*  a  recursive  analysis  must  be  done  here.  */ 
return  (0);  /‘for  now  */ 

) 

else  if  (*temp_old  »«  'S')  { 

/*  another  recursive  analysis  */ 
return  (0);  /"for  now  »/ 

) 

else  { 

next_element (temp_new) ; 
next_element (temp_old) ; 

) 

) 

/*  the  following  two  cases  are  for  0  arguments.  */ 
else  if  (*temp_new  ==  'S')  ( 

next_element (temp_new) ; 

) 

else  if  (*temp_old  =='$')  < 

next_element (temp_ola) ; 

> 

else 

return (0)  ; 

)  /*  end  while  */ 

if  (<*temp_new  -«  '\0')  Si  (»temp_old  ==  XREF_DELIMITER) ) 

/’  both  at  end  of  formals  */ 
return (1) ; 
return (0) ; 

i 


/*  routines  used  in  resolving  types  and  references.  V 
char  "myalloc  (req_size) 
int  req_size; 

{ 

char  *p; 

if  ( (p  »  (char  *)  alloc  (req_size) )  -=  NULL) 

xerr ("No  more  Dynamic  Storage  Available",  0,0,0); 
return (p) ; 

) 


char  *save_string  (s) 
char  *s; 
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char 


*  r>  • 

K' 

p  =  myailoc (strlen (s)  +  1); 
strcpy  (p,  s)  ; 
return  (p) ; 


char  * loose_st ring (s) 
char  *s; 
f 

free (s) ; 
return (NULL) ; 

> 


/*  at  --  locate  a  character  in  a  string  */ 

char  ’at  (s,  seek_char) 

char  *s; 

char  seek_char; 

( 

for  (;*s  ! *  ' \0’ ;  s+*) 

if  (*s  seek_char) 
return ( s ) ; 
return (NULL) ; 

) 


/’  substr  --  return  a  substring  of  the  original  string  ’/ 
char  ’substr  (start_pos,  iast_pcs) 
char  *start_pos,  ’last_pos; 

i 

char  ’ret_string; 
char  ’tmp_ptr; 

if  (start_pos  ==  NULL) 
return  (NULL) ; 
else  if  (last_pos  ==  NULL) 

return  (save_string (start_pos) )  ; 
else  { 

ret_string  =  mya 1 loc ( last_pcs  -  start  pos  +  2)  ; 

for  (tmp_ptr  =  ret_string;  start_pos  <*  last_pos  ;  last_pos++,  tmp_ptr++) 
’tmp_ptr  =  *start_pos; 


) 


char  *eiement_substr (s) 
char  *s; 

< 

char  *last_elem; 

if  (  (last_eierr  »  at(s,  ELEK_DELIMITEK)  )  !=  NULL) 

return  (substr  (s,  --last_elen--)  )  ; 
return (substr (s,  last  elem) ) ; 
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char  *get_arg_type  (actuals,  cur_arg) 
char  ’actuals; 
int  cur_arg; 

< 

int  tmp; 

for  (tmp  -  1;  ((tmp  !«  cur_arg)  it  'FN3_ACTUALS (actuals) )  ;  tmp++) 
next_element  (actuals)  ; 
if  END_ACT'JALS  (actuals) 
return (NULL) ; 

return (element_substr (actuals) ) ; 

) 


int  is_pair(s) 
char  *s; 

( 

for  (;  !END_FORMALS (s)  tl  ! END_ACTUALS (s!  it  !END_ELEMENT (s)  ;  s++) 
if  (  (*s  —  ':')  it  (*(s  +  1)  —  ':')) 
return  (1)  ; 
return (0)  ; 

) 


int  names_match  (element!.,  element2) 
char  *elementl,  ’element2; 

( 

for  (;  ’element  1  =«  *element2  ;) 
if  (’elementl  ==  ':') 
return  ( 1) ; 
return  (0)  ; 

) 


int  mystrcmp  (argl,  arg2) 
char  ’argl,  *arg2; 

1 

for  (;  ((’argl  —  *arg2)  I!  (END_FCRMALS (argl)  it  END_ACTUALS (arg2 ' 
if  (END_FORMALS (argl) ) 
return  ( 1 ) ; 
return  (0)  ; 

) 


int  pullout_xref  (str) 
char  *str; 

{ 

char  *start_pos,  *end_pos; 
char  tmp_char; 
int  retval; 

start_pos  '  at (str,  XREF_DF  IMITER) ; 
end_pos  -  at (str,  PAT7ERN_D£LIMITER) ; 
tmp_char  «  *end_pos; 

*end_pos  =  ' \0’ ; 

retval  =  vs2 i (start_pos) ; 

»end_pos  -  tmp_char; 
return ( retval )  ; 

} 
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int  type_match  (formal,  actual) 
char  ‘formal,  ‘actual; 

( 

for  (;  ‘formal**  !*  ;) 

;  /‘move  past  name  ’/ 
if  (mystrcmp ( formal,  actual)) 
return  (1) ; 

else  if  (mystrcmp ( formal ,  UNDEFINED_TYPE)  II 
mystrcmp (actual,  UND£FINED_TYPE)  ) 
return (1) ; 
return  (0) ; 

) 


/’ 

function  match_fa  : 

--  checks  if  formals  match  actuals. 

--  returns:  true  or  false. 

*/ 

int  match_fa  (formals,  actuals) 
char  ‘formals,  ‘actuals; 

while  ( ! END_FORMALS (formals)  44  IEND_ACTUA1E (actuals) )  ( 

if  (‘formals  ==  ' S' ) 

if  (is_pair (actuals) ) 

if  (names_match (formals,  actuals))  ! 
next_element (formals)  ; 
next_element (actuals)  ; 

else 

next_elemer.t  (formals)  ; 
else  if  (type_match  (formals,  actuals)) 
next_elemer.t  (actuals)  ; 

else 

next_elenent (formals) ; 

else  • 

if  ( is_pair (actuals) )  (  /*  name  must  bind  */ 

if  (I names_match ( formals,  actuals)) 
return (0) ; 

else  (  /*  advance  actuals  past  bind  •/ 

for  (;  ‘actuals**  !=  ;) 

actuals**; 

; 

)  /*  end  if  is_pair  */ 
if  (types_match ( formals,  actuals))  ( 
r.ext_eiement  (formals!  ; 
next_element  (actuals)  ; 

) 

else 

return  (0 )  ; 


107 


) 

if  (£NJ_FORMALS (fermals)  ((  END_ACTUALS (actuals! ) 

return  (1)  ; 
return  (0 )  ; 


int  Analyze_patterns (pattern_string,  actual_args) 
char  *pattern_string; 
char  *actual_args; 

( 

char  *tmp_ptr,  *cur_pattern; 

if  ( (cur_pattern  *  pattern_string)  —  NULL) 
return  (0)-; 

while  (more_sig_patterns (cur_pattern) )  ( 

if  (match__fa  (cur_pattern,  actual_args)  ) 
return  (pullout_xref (cur_pattern)  )  ; 

else 

next_pattern (cur_pattern) ; 

) 

return ( 0 ) ; 


xstring  vseek_symbol  (name,  actual_args,  visible_names,  stbl,  stbl_classes, 
stbi_names,  line_num) 
xobject  name,  actual_args; 
xobject  visible_names; 

xobject  stbl,  stbl_classes,  stbl_names; 
int  line_num; 

xstring  patterns; 

int  xref_vaiue,  cur_arg,  tmp_xref_va 1 ; 
char  *arg_type_name; 
char  *f lat_patterns,  *f lat_actuals; 
char  *other_overloadings  =  NULL; 

patterns  =  xsmapslkup (name,  visible_names) ; 
flat_actuals  =  save_st ring (xtstr flatten (actuai_args )) ; 
xref_value  *  Ana lyze_pat terns ( f iat_pat terns ,  f iat_actua 1 s ) ; 
cur_arg  *  1; 

/*  search  all  other  modules  for  overloadings  */ 

while  ( (arg_type_name  =  get_arg_type (flat_actuals,  cur_arg) )  !=  NULL)  ( 

if  (strcmp (arg_type_name,  xtstrfiatten (xsmapslkup (visible_names, 

CURRENT_MODULE_TAG) ) ) )  { 

/*  not  current  module  */ 

patterns  =  xsmapslkup (xsmapxlkup (stbl ,  arg_type_name) ,  name) ; 
f  lat_patterns  ■=  loose_string  (f  lat_patterns)  ; 
f lat_patterns  =  save_string (xtstrflatten (patterns) ) ; 
tmp_xref_val  =  Analyze_patterns (f iat_patterns,  f lat_actuals) ; 
if  (ximapilkup (stbl_classes,  tmp_xref_va 1 )  ==  MESSAGE_CLASS)  ( 
if  (xref_value  a  tmp_xref_val )  1 
/*  multiple  overloadings  */ 
if  (other_overloadings  ««  NULL) 

other_overloadings  =  vfmtCts  or  %s", 
xrmapslkup (stbl_names,  xref_value) , 
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else 


ximapslkup (stbl_names,  tmp_xref_val )  ); 


other_overloadings  -  vfmt("%s,  %s", 

ximapslkup  (stbi_names,  tmp_xref_val)  , 

) 

else  if  ( ! xref_value) 

xref_value  =  tmp_xref_val; 

1 

) 


cur_arg++; 

)  /*  end  of  while  loop  */ 


other_overloadings) ; 


if  (other_overloadings  ==  NULL) 
return  vi2s (xref_value) ; 

return  verror_message (NONSPECIFIC_REFERENCE,  line_num,  other_over loadings ) ; 


8.  SPEC.M4. 


version  stamp  $Header:  spec.k.v  1.10  89/02/11  20:11:31  berzins  Locked  S 
Kopas-  Revised  Grammar  iaw  v  1.11  05  April  89 
Kopas-  Completed  Declarations  20  April  89 

In  the  grammar,  comments  go  from  a  "!"  to  the  end  of  the  line. 

Terminal  symbols  are  entirely  upper  case  or  enclosed  in  single  quotes  ('). 
Nonterminal  symbols  are  entirely  lower  case. 

Lexical  character  classes  start  with  a  captial  letter  and  are  enclosed  in  (}. 
In  a  regular  expression,  x+  means  one  or  more  x's. 

In  a  regular  expression,  x*  means  zero  or  more  x's. 

In  a  regular  expression,  (xyzj  means  x  or  y  or  z. 

In  a  regular  expression,  [Axyz]  means  any  character  except  x  or  y  or  z. 

In  a  regular  expression,  ia-zj  means  any  character  between  a  and  z. 

In  a  regular  expression,  .  means  any  character  except  newline. 


!m4  inclusion 

files:  mymac.m< 

include (macros 

.m4 ) 

!  definitions 

of  lexical  classes 

%def ine 

Digit 

: 10-9] 

%def ine 

Int 

: (Digit )  + 

%def ine 

Letter 

: [a-zA-Z] 

tdef ine 

Alpha 

: ((Letter) 1 (Digit)  1"  ") 

%def ine 

Blank 

:[  \t\n] 

%def ine 

Quote 

:  ["] 

%def  me 

Backslash 

%def  ire 

Cha  r 

:  (  [A"\\]  1 (Backslash) (Quote) I (Backs 

lash ) (Backslash  • ) 

!  ce f  ir.  it.  ior.s 

cf  white  space  and  comments 

: (Blank } + 

: . *"\n" 


definitions  cf  compound  symbols  and  keywords 
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!  I  had  to  add  the  following  terminal  names  to  get  line  numbers... 


LBRACK  • " [ » 

DOTMARK  : » . « 

SLASH  : 

STARMARX  :»»« 

MINUSMARK  :«_■ 

PLUSMARK  :»+» 

EQUALS  . ... 

GT 

LT  : ■<» 

QUESTION  MARK  :»■>« 


lend  of  my  additions 

AND 

OR 

NOT 

IMPLIES 

IFF 


"** 

■I" 


««>» 


LE 

GE 

NE 

NLT 

NGT 

NLE 

NGE 

EQV 

NEQV 


RANGE 

APPEND 

MOD 

EXP 


{Backslash } I  MOD 


BIND 

ARROrt  • 


THEN  ; THEN 

ELSE  * r ’  cr- 


ALL 

:  ALL 

SOME 

:  SOME 

NUMBER 

: NUMBER 

SUM 

:  SUM 

PRODUCT 

:PRODUCT 

SET 

:  SET 

MAXIMUM 

:MAXIMUM 

MINIMUM 

:MINIMUM 

UNION 

: UN  ION 

INTERSECTION- 

: INTERSECTION 

SUCH 

:S’JCH  (Blank  }*THAT 

ELSE_IF 

: ELSE (Blank ) *IF 

AS 

:  AS 

CHOOSE 

: CHOOSE 

CONCEPT 

: CONCEPT 

DEFINITION 

: DEFINITION 
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DELAY 

DO 

END 

EXCEPTION 

EXPORT 

FI 

FOREACH 

FROM 

FUNCTION 

GENERATE 

HIDE 

IMPORT 

INHERIT 

INITIALLY 

INSTANCE 

INVARIANT 

MACHINE 

MESSAGE 

MODEL 

OD 

OF 

OPERA.TOR 

OTHERWISE 

PERIOD 

RENAME 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION 

TRANSITION- 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 


:  DELAY 
:  DO 
:  END 

:  EXCEPT ION 
:EXPORT 
:  FI 

:  FOREACH 
:  FROM 
iFUNCTION 
:  GENERATE 
:HIDE 
:  IMPORT 
:  INHERIT 
:  INITIALLY 
:  INSTANCE 
:  INVARIANT 
:  MACHINE 
:  MESSAGE 
:  MODEL 
:  OD 
:  OF 

OPERATOR 

OTHERWISE 

PERIOD 

RENAME 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION- 

TRANSITION 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 


INTEGER  LITERAL 
REAL_LITERAL 
CHAR_LITERAL 
STRING  LITERAL 


:  I  Ir.t } 

:  !Int>  "."{Ir.t} 

: {Quotej {Char}’ (Quote 


NAME 


:  (  Letter  }  (Alpha  ;>  * 


operator  preceuerces 
:  tleft  near.s  2-3-»4  is  (2->3)*<. 


tleft 
%  left 
%lef  t 
%  left 
%  .eft 
t.eft 
tleft 
»>f: 
t.eft 
t-o-asscc 
%  lef  t 
tleft 


IF,  DO,  EXCEPTION,  NAME,  SEMI; 

' , ' ,  COMMA; 

SUCH; 

IFF; 

IMPLIES; 

OP  ; 

AND; 

NOT  ; 

LT,  GT,  EQUALS,  LE,  GE,  NE,  NLT,  NOT,  NLE,  NGE,  EQV,  NEQV; 
IN,  RANGE; 

U,  APPEND; 

r LUSMARR ,  MI  STS  MARK.  PLUS,  MINUS; 
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%  left  STAR  MARK,  SLASH,  M'JL,  DTV,  MOD; 

%left  UMINUS  ; 

♦  left  EXP; 

Heft  'S',  LBRACK,  '(',  DOTMARK,  DOT,  WHERE; 

% le  f  t  STAR; 

♦  ♦ 

!attribute  declarations 
ITerminals  First 

BIND,  ARROW,  IF,  THEN,  ELSE,  ALL,  SOME,  NUMBER,  SUM,  PRODUCT,  SET,  MAXIMUM, 
MINIMUM,  UNION,  INTERSECTION,  SUCH,  ELSE_IF,  AS,  CHOOSE,  CONCEPT,  DEFINITION, 
DELAY,  DO,  END,  EXCEPTION,  EXPORT,  FI,  FOREACH,  FROM,  FUNCTION,  GENERATE,  HIDE, 
IMPORT,  INHERIT,  INITIALLY,  INSTANCE,  INVARIANT,  MACHINE,  MESSAGE,  MODEL,  OD,  OF, 
OPERATOR,  OTHERWISE,  PERIOD,  RENAME,  REPLY,  SEND,  STATE,  TEMPORAL,  TIME,  TO, 
TRANSACTION,  TRANSITION,  TYPE,  VALUE,  VIRTUAL,  WHEN,  WHERE  ( 

%line  :  int; 

) 

QUESTION_MARK,  LT,  GT,  EQUALS,  PLUSMARK,  MINUSMARK,  STARMARK,  SLASH, 

DOTMARK,  LBRACK  ( 

♦line  :  int; 

♦text  :  string; 


NOT,  AND,  OR,  IMPLIES,  IFF,  LE,  GE,  NE,  NLT,  NGT,  NLE,  NGE,  EQV,  NEQV, 
MOD,  EXP,  U,  APPEND,  IN,  RANGE  ( 

♦text  :  string; 

♦line  :  int; 


INTEGER_LITERAL,  REAL_LITERAL,  CHAR_LITERAL,  STRING_LITERAL  ( 
♦text  :  string; 

♦line  :  int ; 

) 


NAME  { 

♦  text 

♦  line 


!Now  Nonterminals, 
spec  f 

mod_types_s  :  string->string->string; 
globai_type_s :  string->string; 
type_table_i  :  strir,g->string->string; 

ip_mxref_s  ;  string->string; 

IP_STBL_INFO; 

ip_mcmxref_i  :  st  r  ir.g->st  r  in.g  ; 
ip_lclzd_mcmxref_s  :  st r ing-> st ring- >st ring; 
STBL_ INFO; 

error_rsgs_s  :string; 


rode  I e  1 
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mod_types_s  :  st  r  ing->  st  r  ir.g->  s  t  r  ing  ; 
giobal_t ype_s  :  string->strir.g; 
type_tabie_i  :  st r ing-> st r tng->st r ing; 

ip_mxref  s  :  st r ing->st ring; 
ip_mxref_i  :  string-xstring; 

IP_STBL_INF 0; 

STBL_INF0; 

ip_lclzd_mcmxref_s  :  string->string->string 
ip_mcmxref_i  :  string->string; 

error  msgs_s  :  string; 

) 

function  ( 

moduie_name_s  :  string; 
mxref_value_s  ;  int; 

mod_types_s  :  string->string->string; 
type_table_i  :  string->string->string; 

ip_mxref_s  :  st ring->st ring; 
ip_ir.xref_i  :  string->string; 

IP_STBL_INFO; 

STBL_IN'FO; 

IP_MCMXREF_TBLS; 

error_msgs_s  :  string; 


machine  { 

moduie_name_s  :  string; 
mxref_value_s  :  int; 
mod_types_s  :  string->string->st ring; 
type_table_i  :  string->string->string; 

ip_mxref_s  ;  string->string; 
ip_rr.xref_i  :  string->string; 
IP_STBL_INFO; 

STBE_INFC; 

IP_MCMXREF_TBLS ; 

error_m.sgs_s  :  string; 


t  ype  { 

modu le_rame_s  :  string; 
mxref_value_s  ;  int; 
mod_types_s  :  string->string->string; 
global_type_s :  string->string; 
type_table_i  :  string->string->string; 

ip_rrj<ref_s  :  st r ing->st ring; 
rp_mxref_i  :  st r i ng->st r ing; 
IP_S7BL_:h'FC; 

STBL_INF0; 

:p_MCMXREF_TBLS; 

error_rr.sgs_s  :  string; 
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definition  { 

module_name_s  :  string; 
mxref_vaiue_s  :  int; 

mod_types_s  ;  st r ing->st r ing->st r ing ; 
type_table_i  :  string->string~>string; 

ip_mxref_s  :  string->string; 
ip_mxref_i  :  string->string; 
IP_STBL_INFO; 

STBL_INFO; 

IP_MCMXREF_TBLS ; 

error_msgs_s  :  string; 

) 

instance  ( 

module_name_s  :  string; 
mxref_value_s  :  int; 

type_table_i  :  string->string->string; 

ip_mxref_s  :  string->string; 
ip_mxref_i  :  str ing->string; 
IP_STBL_INFO; 

STBL_INFO; 

IP_MCMXREF_TBLS ; 

error_msgs_s  :  string; 
d_error_s  :  string; 

) 

interface  ( 

module_name_s  :  string; 
mxref_value_s  :  int; 

type_table_i  :  string->string->string; 
env_i  :  int; 

VISIBILITY_TBLS; 

ip_mxref_s  :  string->string; 
ip_mxref_i  :  string->string; 
IP_STBL_INFO; 

STBL_INFC; 

error_msgs_s  ;  string; 
d_error_s  :  string; 

) 

inherits  ! 

error_msgs_s  :  string; 


) 

hide  ( 

error_msgs_s  :  string; 

I 

renames  ■ 

errcrrsgs  s  :  string; 
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:  string->stri.ng->string; 


imports  < 

type_tabie_i 

v:sibil:ty_t3ls; 

XP_STBL_INFO; 

STBL_INFO; 

error_msgs_s  :  string; 


export  ( 

error_msgs_s  :  string; 

} 


messages  ( 

VISIBILITY_TBLS; 

IP_MCMXR£F_TBLS  ; 

IP_STBL_INFO; 

STBX_INFO; 

error_msgs_s  :  string; 

} 

message  { 

vxs:B:i.:Ty_TBLS; 

IP_MCMXREF_T31S; 

IP_STBX_IN'FC; 

STBL  INFO; 


error_msgs_s  :  string; 

i 


response  { 

xref_value_i  :  ir.t; 

vis:3:i:Ty_rBLS; 

XP_SX3L_:nFC; 

STBL_INFO; 

error_msgs_s  ;  string; 


response_cases  i 

xre  f_value_ :  :  ir.t; 

visib:l:ty_tbls; 

IP_STBX_:nFC; 

STBL_INFO; 

errcr_rsgs  s  :  strir.o; 
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) 


response_body  f 

xrefvaluei  :  int; 

VISIBILITY_TBLS; 

IP_STBL_INFO; 

STBL_INFO; 

error_msgs_s  :  string; 


choose  { 

VISIBILITY_TBLS; 

IP_STBL_INFO; 
STBL  INFO; 


error_msgs_s  :  string; 

} 


reply  ( 

xref  value  i  :  int; 


VISIBILITY_TBLS; 

IP_STBL_INFO; 

STBL_INFO; 

error_msgs_s  :  string; 

) 


sends  { 

VISIBILITY_TBLS; 

:p_stbi_infc; 

STB1  INFO; 


error_msgs_s  :  string; 

) 


send  { 

VISIBILITY_TBLS ; 

IP_ST3L_INF0; 
STB!  INFO; 


error_msgs_s  :  string; 


V:SIBILITY_TBLS; 
IF  STBL  INFO; 


1 


ST3L_INF0; 

error_ir.sgs_s  :  string; 


formal_message  ( 

xref_value_s  :  int; 
message_name_s  :  string; 
message_fargs_s  :  string; 

VISIBILITY_TBLS ; 

IP_MCMXREF_TBLS ; 
IP_STBL_INFO; 

STBL_INFO; 

d_error_s  :  string; 
error_msgs_s  :  string; 

) 


actual_message  • 

actual_text_s  :  string; 
VISIBILITY_TBLS; 

IP_STBL_INFO; 

STBL_INFO; 

error_msgs_s  :  string; 


) 

where  ( 

v:sib:lity_tb’„s; 

IP_STBL_INFC; 

S?il_IN’FO; 

error_p.sgs_s  :  string; 


optionaiiy_virtuai  { 

visib:l:ty_tb-_s; 

IP_STBL_INFO; 

STBL_INFO; 

error_msgs_s  ;  string; 


opt iona l_except icr  •; 

visibility  tsls; 


:P_STBL_IN'FO; 

ST31_:NFC; 
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error_msgs_s  :  string; 


operator  ( 

xref_value_i  :  int; 
message_f args_i  :  string; 
line_s  :  int; 

VISIBILITYJTBLS; 

IP_MCMXREF_TBLS ; 
IP_STBL_INFO; 

STBL_INFO; 

error_msgs_s  :  string; 


optional_foreach  ! 
VISIBILIi Y_TBLS; 

IP_ST3L_INF0; 

STBL_INFO; 

error_msgs_s  ;  string; 


foreach  1 

VISIBILITYJTBLS; 

IP_STBL_INFO; 
STB!  INFO; 


error_msgs_s  :  string; 

> 


concepts  ( 

moriuie_name_i  :  string; 
local_types_s  :  string->string; 
VISI3ILITY_TBLS; 

IP_MCMXREF_TBLS; 

IP_STBL_INFO; 

STBL_INFO; 

error_msgs_s  ;  string; 

> 

concept  { 

loca i_types_s  :  string->st ring; 
modu le_name_i  :  string; 
xref  value  s  :  int; 
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VISIBILITY  TBLS; 


IPMCMXREFTBLS ; 

IP_STBL_INFC; 

STBL_INFO; 

error_msgs_s  :  string; 
d_error_s  :  string; 


mode 1  ( 

VISIBILITY_TBLS; 

IP_STBL_INFO; 
STBL  INFO; 


error_msgs_s  :  string; 

1 


state  ( 

VISIBILITY_TBLS; 

IP_STBL_INFO; 
STBL  INFO; 


error_msgs_s  :  string; 


invariant  { 

VISIBILITY  TBLS; 


IP_STBL_INFO; 
STBL  INFO; 


errcr_msgs_s  :  string; 


initially  ' 

VISIBILITY  TBLS; 


IP_ST3L_INFC; 

STBL_INFO; 


} 


e 


rror_msgs_s 


s 


ing; 


transactions  f 

VISI3ILITY_TBLS; 

IP_ST3L_INF0; 

STBL_INrO; 

error_msgs  s  ;  string; 
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transaction  { 

d_error_s  :  string; 

VISIBILITY  TBLS ; 


IP_S?BL_INFO; 

STBL_INFO; 

error_msgs_s  :  string; 

) 


action_list  ( 

VISIBILITY_TBLS; 

IP_STBL_INFO; 

STBL_INFO; 

error_msgs_s  :  string; 


) 


action  ( 

VISIBILITY_TBLS; 

IP_STBL_INFO; 

STBL_INFO; 


error_msgs_s  :  string; 

) 


alternatives  ( 

VISI3ILITY_TBLS; 

IP_STBL_INFC; 
Sill  INFO; 


error_rr,sgs_s  :  string; 

) 


guard  f 

VISIBILITY_TBLS; 

IP_STBL_INFO; 
STBL  INFO; 


error_rr.sgs_s  :  string; 


) 


te.Tporals  f 

VISIBILITY_TBLS; 

’?  ST31  INFO; 
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STB^_INFC; 

errcr_nsgs_s  :  string; 


temporal  { 

xref_value_s  :  int; 
d_error_s  :  string; 

VISIBILITY_TBLS; 

IP_STBL_INFO; 

STBL_INFO; 

error_msgs_s  :  string; 


opt ional_formai_name  { 

name_text_s  :  string; 
name_params__s  :  string; 
args_i  :  string; 
env_i  :  int; 
xref_value_s  :  int; 
iine_s  :  int; 

VISIBILITY__?BI.S  ; 

IP_STBL_INFO; 

STBL_INFO; 

error_msgs_s  :  string; 


fcrmal_name  { 

nametexts:  string; 

nane_pa ran s_s  :  string; 

er.v  i  :  int; 

xre f_va iue_s  :  int; 

args_i  :  string; 

lin e_s  :  int; 

sign  atjre_s  :  string; 

VISIBILITY_TBLS ; 

I?_STBL_INFO; 

STBL_INFO; 

er ror_msgs_s  :  string; 
d_errcr_s  :  string; 


f  orr.a  l_paramet  e  r  s  < 

narne__pa:ans  s  :  string; 
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VISIBILITY  TBLS ; 


IP_STBL_INFO; 

STBL_INFC; 

error_msgs_s  :  string; 

} 


formal_arguments  { 

name_fargs_s  :  string; 
args_text_s  :  string; 

IP_STBL_INFO; 

STBL_INFO; 

VISIBILITY_TBLS; 

error_rosgs_s  :  string; 

) 

field_list  { 

f ieldpattern^s  :  string; 
text_s  :  string; 

IP_STBL_INFO; 

STBL_INFO; 

VISIBILITY_TBLS ; 

error_msgs_s  :  string; 

) 

field  { 

f ieidpattern_s  :  string; 
text_s  :  string; 
xref_value_s  :  int; 
d_error_s  :  string; 

IP_STBL_INFC; 

STBL_INFO; 

VISIBILITY_TBLS; 
error_msgs_s  :  string; 

) 

aeclname_list  i 

name_type_text_i  ;  string; 
name_type_value_i  :  string; 
f ieldpattern_s  :  string; 
xref_value_s  :  int; 
text_s  :  string; 
d_error_s  :  string; 

IP_STBL_INFO; 

STBL_INFC; 

VIS IBILITY_TBLS ; 

error_nsgs_s  :  string; 


322 


type_spec  i 

type_name_text_s  :  string; 
type_r»ame_value_s  ;  string; 

IP_STBL_INFC; 

STBL_INFO; 

VISIBILITY_TBLS ; 

error_msgs_s  :  string; 
tmp_msg  :  string; 

} 


name_list  { 

error_msgs_s  :  string; 

) 

opt iona l_actual_name  { 

full_name_s  :  string; 
actual_params_s  :  string; 
actual_name_text_s  :  string; 
line_s  :  int; 

IP_STBl_INFO; 

STBL_INFO; 


VISIBILITY_7BLS; 
error_msgs_s  :  string; 


actuai_name  { 

actual_name_text_s  :  string; 
fuii_nane_s  :  string; 
actual_paraiTiS_s  ;  string; 
line_s  :  int; 

IP_STBL_INFO; 

STBL_INFC; 

VISIBILITY_TBLS; 

error_msgs_s  :  string; 


actua i_paraneters  ( 

act'jal_pararts  s  :  string; 

IP_STBL_INFC; 

STBL_INFO; 

v:s:b:l:-ty_t31S; 

error_rsgs_s  :  string; 
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act.ua l_argumer.t s  ( 

fuli_args_s  :  string; 

IP_STBL_INFO; 

ST3L_INFC; 

VISIBILITYJTBLS; 

error_msgs_s  :  string; 


value_arguments  ( 

xref  value  i  :  int; 


IP_STBL_INFO; 

STBL_INFO; 

VISIBILITY_TBLS; 

error_msgs_s  :  string; 


arg_list  ( 

arglist_text_s  :  string; 


IP_STBL_INFO; 
STBL  INFO; 


VISIBILITY  TBLS; 


) 


error_msgs_s  :  string; 


arg  f 

arg_text_s  :  string; 

IP_ST3L_INFC; 

STBL_INFC; 

VISIBILITY  TBLS; 


1 


error_rr.sgs_s  ;  string; 


expression_list  ( 

xten_type_s  :  string; 

IP_STBL_INFO; 

STBL_INFO; 

VISIBILITY_T3LS; 

error_msgs_s  :  string; 
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expression  { 

xter._type_s  :  string; 

IP_STBL_INFC; 

ST3L_ INFO; 

VISIBILITY_TBLS; 

error_msgs_s  :  string; 


middle_cases  { 

IP_S?BL_INFO; 

STBL_INFO; 

VISIBILITY_TBLS; 

error_msgs_s  :  string; 


IP_STBL_INFC; 

STBL_INFO; 

VIS IBILITY_TBLS; 

error_msgs_s  :  string; 


xten_t ype  s  :  string; 


IP_STBL_INFO; 

S  73L_ I NFC ; 

VISIBILITY  TBLS ; 


error  _rrsgs_s  :  string; 


expressions  { 

xten _type_s  :  string; 

IP_S73L_INFO; 
5T3L_INFC; 

v:s:b:l:':y_t3ls; 

error 


rr,sgs_s  :  string 


pair_list  ( 

xten_type_s  :  string; 


IP_STBL_INFO; 
STBL  INFO; 


VISIBILITY  TBLS ; 


error_msgs_s  :  string; 

) 


pair  { 

xtentypes  :  string; 
type_s  :  string; 

IP_STBL_INFO; 

STBL_INFO; 

VISIBILITY_TBLS; 

error_msgs_s  :  string; 


operator_l ist  ( 

xref_value_i  :  int; 
message_fargs_i  :  string; 
line_s  :  int; 

STBL_INFC; 

IP_MCKXREF_TBLS; 

d_error_s  :  string; 
error_msgs_s  :  string; 

} 

cperator_symbcl  ( 

operator_text_s  :  string; 
line_s  :  int; 

) 


M 

!  productions  of  the  grammar 
start 

:  spec 

j 

S  1  ,type_tabie_i  =  $  1 . mod_t ypes_s  +! 

!  (GLOBAL_TYPE_NAMES  :  Si ,global_type_s)  ) 

SI . ip_stbi_ciass_i  =  ((?  :  int  :  FALSE)  ! ; 

S I . ip_stbl_names_i  =  ((?  :  int  :  NULL_STRING)  ); 

SI . ip_stbi_parars_i  =  <(?  :  int  :  NULL_STRING)  ); 

SI  .  ip_st'cl  result  i  =  •'  ( ?  :  int  :  NULL  STRING)  •  ; 


126 


S 1 . stbl_names_i  =  S 1 .  ip_stbi_r.ares_s 
S 1 . stbi_c iass_i  -  S 1 .  ip_stbl  rlass_s 
S 1 . stbl_params_i  =  S 1 . ip_stbi_params 
SI .stbl_resuit_i  =  S 1 .  ip_stbl_result 


s  ; 
s; 


SI .  ip_mcmxref_i  =  SI .  ip_mxref_s; 
Si.stbi_i  =  Si . ip_lclzd_mcmxref_s; 


!  test  values 

♦output ("TYPESXnl .  GlobalXn"); 

♦smaps_dump ( S 1 . t ype_table_i  (GLOBAu_TYPE_NAMES) ) ; 
♦output ("2.  From  module  testl\n"); 

♦smaps_dump (SI . type_tabie_i  ("restl") ) ; 

♦output ("3.  From  module  test4\n"); 

♦smaps_cump (Si . type_tabie_i  ("test4") ) ; 

♦output ("4.  From  module  test7\n"); 

♦smaps_dump ( S 1 . type_table_i  ( "test 7“ ) ) ; 

♦output ("\n\nMODULE  XREF  \nModule  TestlXn") ; 

♦  smaps_dump (SI . stbl_i ("testl") )  ; 

♦  output  ("Module  test4Xr."); 

♦smaps_dump (SI . stbi_i ("test  4 " ) ) ; 

♦  output  ("Module  test7\r."); 

♦  sr.aps_dump  (Si.stbi_i("test7")>; 


!  dump  xref  info  i  error  messages. 

♦output ("\n\n") ; 

♦  output  (" - \n") 

♦output)"-  Error  Messages  t  Cross  Reference  Info  -\n"l 

♦  output  (" - \n") 

♦  output (Si .error_msgs_s)  ; 

♦output ("\n\nCross  Reference  to  Names. \n"); 

♦  xref  s_dump ( S 1 . st bi_names_ i ) ; 

♦  output ("\n\nCross  Reference  to  Name  Classes . \n")  ; 

♦xref i_dump (SI . stbl_class_i ) ; 


♦  output  ("\r.\nCross  Reference  to  Name  Parameters  . \n" )  ; 

♦  xref  s_dum.p  (Si  .  stbl_params_i )  ; 

♦  output  ("\r.\nCross  Reference  tc  Name  Results.  Xr."); 
♦xrefs_dump ( SI . stbi_result_i)  ; 


spec 

:  spec  module 

( 

catmapup2_l (SI, S  2 , ncd_t  ypes ) ; 
catmapup2_I (Si, S2,gioba l_t ype)  ; 

(module  names. 

passovr_l (S 1 ,  S2,  ipmxref) ; 
passup_l(S2,  ip_mxref); 

(symbol  table 
stb-_ouild2  (SI, S2)  ; 
passdt_stDl2 (SI,  S2) ; 

(  pass  down  needed  type  translations. 
passdr.2_l  (SI,  S 2,  type_taoie); 

pa s sdr.2_  1  ( S 1 ,  S2,  ip  rcmxref )  ; 
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catmapup2_l ($1,  $2,  ip_ic 1 zd_mcmxre £ ) ; 

SS ,error_msgs_s  =  [ S 1 . errcr_msgs_s,  $2 .error_msgs_s] ; 


( 

S S . mod_t ype s_s  =  ( (?  :  string  :  < (?  :  string  :  UNDEFINEDJTYPE)  } )  } ; 

SS  .global_type_s  -  {(?  :  string  :  UNDEFIN£D_TYPEI  }; 

!  module  names  t  features. 

SS . ip_mxre£_s  =  { (?  :  string  :  NU_L_STRING) ) ; 

SS . ip_lclzd_mcmxref_s  «  { (?  :  string  :  {(?  :  string  :  NULL_STRING) ) ) ) 

(symbol  table 
stbl_buildO  () ; 

SS .error_msgs_s  » 


!  A  production  with  nothing  after  the  "I"  means  the  empty  string 
!  is  a  legal  replacement  for  the  left  hand  side. 

module 

:  function 

( 

passup_l(Sl,  mod_types) ; 

$$.global_type_s  =  ( (?  :  string  :  UNDEFINEDJTYPE)  ); 

passdn_l($l,  type_table) ; 

! symbol  table 
passiol_l (SI,  ip_mxref)  ; 
stbl_buildl (SI); 
passdr._stbll  (SI); 

passdn_l(Sl,  ip_mcmxref ) ; 

SS . ip_lcizd_mcmxref_s  =  { ( S 1 . moaule_name_s  :  SI . ip_mcmxref_s) ) ; 


passup_l($l,  error_msgs) ; 

) 

machine 

( 

passup_l(Sl,  mod_types); 

S S . globa l_t ype_s  =  { ( ?  :  string  :  UNDEFINEDJTYPE)  ); 
passdn_l (SI,  type_table) ; 


(symbol  table 
passiol_l  (SI,  ip_mxref); 
stbl_buildl (SI)  ; 
passdn_stbll (SI) ; 

passdn_l(Sl,  ip_mcmxref) ; 

SS  .  ip_lclza_mcmxref_s  «  {  (SI  ,moduie_name_s  :  SI .  ip_mcmxref_s)  )  ; 
passup_l(Sl,  error_msgs) ; 

) 
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type 

passup_2(SI,  nod_types,  globai_type) ; 
passdr._I  (SI,  type_table) ; 


! symbol  table 
passiol_l (SI,  ip_mxref) ; 
stbl_buildl  (SI)  ; 
passdn_stbll  (SI) ; 


passdn_l($l,  ip_mcmxref ) ; 

SS . ip_ici2d_mcmxref_s  =  ( (SI .module_name_s  :  $1 . ip_mcmxref_s) ) ; 
passup_l(Sl,  error_msgs) ; 

) 

I  definition 

{ 

passup_l(Sl,  mod_types) ; 

SS .global_type_s  =  ((?  :  string  :  UNDEFINED_TYPE)  ); 
passdn_l(Si,  type_tabie) ; 


! symbol  table 
passiol_l (Si ,  ip_mxref); 
stbl_buildl (SI); 
passan_stbli (SI); 

passdn_I(Sl,  ip_mcm.xref )  ; 

SS  .  ip_lclzd_mcmxref_s  =  (  (S i  .moduie_name_s  :  Si  .  ip_mcmxref_s)  )  ; 
passup_l(Sl,  error_msgs) ; 

I  instance  !  of  a  generic  module 

{ 

S S . mod_types_s  =  { (?  :  string  :  ( (?  :  string  :  UNDEFINED_TYPE)  i)  ) 
S S . globa l_type_s  =  ((?  :  string  :  UNDEFINED_?YPE)  }; 
passdr._l  (Si,  type_table) ; 


! symbol  table 
passioi_l  ( Si ,  ip_rr.xref); 
stbi_buildi (SI)  ; 
passdr._stbll  (Si)  ; 

passdn_l(Si,  ip_mcmxref )  ; 

SS • ip_icizd_mcmxref_s  «  { (SI .module_name_s  :  SI . ip_mcmxref  s)J; 
passup_i(Si,  errcr_msgs) ; 

) 


fun.ct  icn 

:  opt  iota- »y_virtua.  FUNCTION  interface  messages  concepts  END 

pa s s up_2 ( S 3 , module_name ,  mxref  value); 
passcvr_I  (S3 ,  S5,  modu Ie_name) ; 

S3.en.v_:  =  FUNCTION  CLASS; 
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55 .moa_types_s  =  ( (S3 ,module_name_s  :  55  .  local_types_s)  ) ; 

passdn_l(S3,  type_tabie) ; 
passio2_l  (54, 55,  ip_mcmxref)  ; 

(symbol  table 
passiol_l  (S3,  ip_mxref)  ; 
stbl_build3 (S3,  54,  55); 
passdn_stb!3 (S3,  54,  55); 


(visibility  information 

passovr2x_2 (S3,  54,  55,  visible_types,  visible_names) ; 

55 .error_msgs_s  *  [53 .error_msgs_s,  54 .error_msgs_s,  55 .error_msgs_s] ; 


!  Virtual  modules  are  for  inheritance  only,  never  used  directly. 


machine 

:  optionally_virtual  MACHINE  interface  state  messages  transactions  temporals 
concepts  END 
< 

passup_2 (S3, module_name,  mxref_value) ; 
passovr__l  (S3,  58,  module_name)  ; 

S3 .env_i  =  MACHINE_CLASS; 

55 -mod_types_s  =  { (S3 ,module_name_s  :  58 . local_types_s) ) ; 

passdn_l(S3,  typetable) ; 
passio2_l (55,  58, ip_mcmxref ) ; 

(symbol  table 
passiol_l (S3 ,  ip_mxref ) ; 
stbl_bulld6  (S3,  54,  55,  56,  S7,  $8)  ; 
passdn_stbl6  (S3,  54,  55,  56,  57,  58); 

(visibility  information. 

passovr_2  (S3, 54, visible_types,  vis ible_names ) ; 
passovr2x_2 (54, 55, 56, visible_types,  visible_names) ! 
passovr2x_2 (54, 57, 58,  visible_types,  visible_names) ; 

SS .error_msgs_s  =  [S3 .error_msgs_s,  55 ,error_msgs_s,  58 .error_msgs_s] ; 

) 

type 

:  optionally_virtual  TYPE  interface  model  messages  transactions  temporals  concep 

END 

( 

passup_2 (S3, module_name,  mxref_value)  ; 
passovr_l (S3,  58,  module_name) ; 

S3 .env_i  =  TYPE_CLASS; 

55 .mod_types_s  =  (  (S3 ,module_name_s  :  58 . local_types_s  ))  ; 

55 .globai_type_s  =  ( (S3 .module_name_s  :  S3 ,module_name_s) , 

(?  :  string  :  UNDEF INED_TYPE)  ) ; 

passdr._l  (S3,  type_table); 
pa ssio2_l ( S5 ,  58,  ip_mcmxref) ; 

(symbol  table 

passicl  1  (S3,  ip_mxref!; 
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stbl_build6 (S3,  $4,  S5,  $6,  S7,  S  8 ) ; 
passdr,_stb!6  (S3,  $4,  $5,  $6,  $7,  S8)  ; 


(visibility  information. 

passovr_2 ( S3 , S  4 , visible_types,  vi sible_names) ; 
passovr2x_2 ($4, $5, $6, visible_types,  visible_namea) ; 
passovr2x_2 (S4, S7( S8,  visible_types,  visible_name») ; 

SS .error_msgs_s  »  [S3 .error_msgs_s,  S5 . error_msgs_«,  S8 .error_msgs_s] ; 


definition 

;  DEFINITION  interface  concepts  END 

< 

passup_2 ( $2, module_name,  mxref_value)  ; 
passovr_l ($2,  S3,  module_name) ; 

$2.env_i  *  DEFINITION_CLASS; 

SS -mod_types_s  «  ( (S2 .module_name_s  :  S3 . local_types_s) } ; 

passdn_l(S2,  type_table) ; 
passiol_l (S3,  ip_mcmxref ) ; 

! symbol  table 
passiol_l (S2,  ip_mxref)  ; 
stbl_build2 { S  2 ,  S3)  ; 
passdn_stbI2 ($2,  S3); 

(visibility  information. 

passovr_2 (S2,  S3,  visible_types,  visible_names) ; 

SS .error_msgs_s  =  (S2 .error_msgs_s,  S3 .error_msgs_s] ; 


instance 

:  INSTANCE  formal_name  EQUALS  actual_name  END 

( 

SS .moduie_name_s  =  S2 . name_text_s ; 
S2.env_i  »  INSTANCE_CLASS; 

SS.mxref  value  s  =  S2.xref  value  s; 


passioC_l ( ip_mcmxre . ) ; 

! symbol  table 

SS.d_error_s  =  check_simpie_decl (SS . ip_mxref_i,  SS .module_name_s,  S2.1ine_s, 

SS . stbl_names_i) ; 

rr.k_simple_decl_io  (SS  .  ip_mxref ,  SS ,d_errnr_s,  SS .module_name_s, 

SS .mxref_value_s) ; 
stbl_build2 (S2,  $4); 
passan_stbl2 (S2,  S4); 

Ivisibility  information. 

S2 . vis ibie_types_i  -  SS . type_table_i  (GLOBAL_TYPE_NAMES) ; 

S2 .  visible_names_i  =  SS . stbl_i (SS ,module_name_s) ; 
passovr_2 (S2,  S4,  visibie_types,  visibie_names) ; 

SS . error_msgs_s  =  SS .d_error_s; 
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I  INSTANCE  foreach  actual_name  END 

{ 

!  Check  this  entire  section  of  code  for  interfaces... 

SS .module_name_s  =  S3 .actual_name_text_s;  !check  this  w/  Prof.  B. 

S$  .mxref_value_s  *=  get_new_xref ( S3 . actual_name_text_s) ; 

$S.d_error_s  =  check_simple_decl (SS . ip_mxref_i,  SS .moduie_name_s,  $3. line  s, 

SS . stbl_names_i ) ; 

mk_simple_decl_io (SS . ip_mxref ,  SS .d_error_s,  SS .module_name_s, 

$$ .mxref_value_s) ; 

passioO_l (ip_mcmxref) ; 

(symbol  table 
stbl_build2  (S2, S3) ; 
passdn_stbl2 (S2, S3) ; 

(visibility  information 

S2.visible_types_i  -  SS  .type_table_i  (GLOBAL_TYPE_NAH£S)  ; 

$2 . visible_names_i  «  SS.stbl_i  ($$ .module_name_s) ; 
passovr_2 (S2,  S3,  visible_names,  visible_types) ; 

SS .error_msgs_s  =  SS -d_error_s; 

1 

!  For  making  instances  or  partial  instantiations  of  generic  modules. 

!  The  foreach  clause  allows  defining  sets  of  instances. 

interface 

:  formal_name  inherits  imports  export 

( 

SS .module_name_s  «  S 1 . name_text_s; 

SS .mxref_value_s  *  S 1 . xre f_value_s; 

Sl.args_i  « 
passdn_l(Sl,  env)  ; 

SS.d_error_s  «  check_simpie_deci ( SS . ip_mxref_i,  SS .module_name_s,  Sl.line_s, 

SS . stbl_names_i) ; 

mk_simple_decl_io (SS . ip_mxref ,  SS .d_error_s,  SS ,module_name_s, 

SS.mxref  value  s! ; 


(symbol  table 
stbl_build2 (SI,  S3); 
passdr._stbI2  (S 1 ,  S3); 


(visibility  information 

SI . visible_types_i  =  SS .type_table_i  (GLOBAL_TYPE_NAKES) ; 

SI . visible_names_i  =  S$.stbi_i  (SS .module_name_s)  +1 

( (CURRENT_MODULE_TAG  :  SS .module_name_s) ); 

S3 . visible_types_i  =  SI . visible_types_s  +1 

SS . type_table_i  (SS .module_name_s) ; 
passovr_l (SI,  S3,  visible_names) ; 
passup_2(S3,  visible_types,  visible_names) ; 

SS -error_msgs_s  =  (SS .d_error_s,  SI .error_msgs_s) ; 

This  part  describes  the  static  aspects  of  a  module’s  interface. 

The  dynamic  aspects  of  the  interface  are  described  in  the  messages. 
A  module  is  generic  iff  it  has  parameters. 
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The  parameters  can  be  constrained  by  a  WHERE  clause. 

!  A  module  car.  inherit  the  behavior  of  other  modules. 

!  A  module  can  import  concepts  from  other  modules. 

'  A  module  can  export  concepts  for  use  by  other  modules. 

inherits 

:  inherits  INHERIT  actual_name  hide  renames 

i  > 

I 

<  ) 

Ancestors  are  generalizations  or  simplified  views  of  a  module. 

!  A  module  inherits  all  of  the  behavior  of  its  ancestors. 

!  Hiding  a  message  or  concept  means  it  will  not  be  inherited. 

!  Inherited  components  can  be  renamed  to  avoid  naming  conflicts. 

hide 

:  HIDE  name_list 

<  } 

I 

(  ) 

!  Useful  for  providing  limited  views  of  an  actor. 

!  Different  user  classes  may  see  different  views  of  a  system. 

!  Messages  and  concepts  can  be  hidden. 

renames 

:  renames  RENAME  NAME  AS  NAME 

(  ) 

<  ) 

!  Renaming  is  useful  for  preventing  name  conflicts  when  inheriting 
!  from  multiple  sources,  and  for  adapting  modules  for  new  uses. 

!  The  parameters,  model  and  state  components,  messages,  exceptions, 
!  and  concepts  of  an  actor  can  be  renamed. 

imports 

:  imports  IMPORT  name_list  FROM  actual_name 

{ 

Ivisibility  information. 

passio0_2 (visible_types,  visible_names) ; 

!for  now  --  until  importation  implemented, 
stbljouiidl  (SI)  ; 
passdn_stbll (SI) ; 

) 

I 

< 

Ivisibility  information. 

passioC_2 (visibie_types,  visible_names) ; 

! symbol  table 
stbi_bui iaC  ()  ; 


export 

:  EXPORT  name  list 
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messages 


(  } 
{  ) 


:  messages  message 

{ 

passio2_l (SI,  $2,  ip_mcmxref) ; 

(aymbol  table 
stbl_build2 (SI,  $2) ; 
paasdn_stbl2 ($1,  S2); 

(visibility  information 

passdn2_2 (SI, $2,  visible_types,  visible_names) ; 

(error  messages 

SS -error_msgs_s  «  IS1 .error_msgs_s,  $2. error  msgs_s]; 


passioO_l (ip_mcmxref) ; 

'symbol  table 
stbl_buildC ()  ; 


(error  messages 
SS  .error_msgs_s  = 


message 

:  MESSAGE  forma i^message  operator  response 

{ 

passio2_l (S2,  S3,  ip_mcmxref) ; 

passovr_2  ( S 2 ,  S3,  xref__value,  message_f args)  ; 
passovr_l (S2,  S4,  xref_value) ; 

(symbol  table 
stbl_build3  ( 52 ,  S3,  S4 ) ; 
passdn_stbl3  ( S  2 ,  S3,  SO; 

(visibility  information 

passar._2  (S2,  visible_types,  vi sible_names)  ; 
passovr_2 (S2,  $4,  visible_types,  visible_names) ; 

(error  messages 

SS .error_msgs_s  =  [ S2 . error_msgs_s,  S3 ,error_msgs_s,  S4.error_msgs_s 


response 

:  response_body 

( 

passdr,_l  ( Si ,  xref_value); 

(symbol  table 
st bl_bj i idl  (SI)  ; 
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passar._stbll  (SI)  ; 

(visibility  inf orma: ion 

passa.-._2  (SI,  visible_types,  visible_names) ; 

I  error_messages 
passup_l(51,  error_msgs) ; 
i 

I  respo.nse_cases 

( 

passdr>_l($i,  xref  vOue); 

Isymbol  table 
stbl_buildl ($1) ; 

(visibility  information 

passdn_2(Sl,  visible_types ,  visible_names) ; 

!error_messages 
passup_l (SI,  errcr_msgs) ; 

) 


respor.se_cases 

:  WHEN  expressior._i ist  response_body  response_cases 

{ 

passdn2_l (S3,  S4 ,  xref_value) ; 

Isymbol  table 
stbl_buila3  (S2,  S3,  SO; 
passd.n_stb!3  (S2,  S3,  SO  ; 

Ivisibility  information 

passdr,3_2  (S2,  S3,  SO  visible__types,  visible_names> ; 

I  error_messages 

SS  .errcr_msgs_s  =  ( S2  ,error_msgs_s,  S3  .error_msgs_s,  $4 .error_msgs 

OTHERWISE  respon se_body 

( 

passdr._l($2,  xref_value)  ; 

Isymbol  table 
stbl_builal  ( S 2  )  ; 
passdr._stbll  (S2)  ; 

Ivisibility  information 

passdr._2  (S2,  visible_types,  visible_names)  ; 

I e r re r_mes sages 
passup_l  (S2,  error_msgs); 


response_body 

:  choose  reply  sends  transition 
passdn_l(S2,  xrefvalue) ; 

I  symbol  table 
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stbl_build4 (SI,  S2,  S3,  S4); 
passdn_stb!4 (SI,  S2,  S3,  $4); 

(visibility  information 

passdn_2(Sl,  visibie_types,  visible_names) ; 

passovr3x_2 (SI,  S2,  S3,  $4,  visible_types,  visible_names) ; 

(error  messages 

$S .error_msgs_s  «  [ S 1 .error_msgs_s ,  S2 .error_msgs_s,  S3 .error_msgs_s, 
$4 ,error_msgs_s] ; 


choose 

:  CHOOSE  '('  field_list  restriction  ')' 

< 

(symbol  table 
stbl_build2 (S3,  S4); 
passdn_stbl2 (S3,  S4); 

(visibility  information 

passiol_2 (S3,  visible_types,  visible_names) ; 
passovr_2 (S3,  S4,  visible_types,  visible_names) ; 

(error  messages 

SS -error_msgs_s  =  [ S3 . error_msgs_s,  $4 .error_msgs_s] ; 

/ 

I 

{ 

(symbol  table 
stbi_buildO  ()  ; 

(visibility  information 

passio0_2 ( visible_types,  visible_names) ; 

(error  messages 
SS -error_msgs_s  = 

) 

reply 

:  REPLY  actuai_message  where 

( 

(symbol  table 

passio2_3 (S2,  S3,  ip_stbl_class,  ip_stbl_names,  ip_stbl_params> ; 
S2 . ip_stbi_result_i  =  SS . ip_stbl_result_i  +1 

( (SS . xref_va lue_i  : 

S2 .actual_text_s) ) ; 
passovr_l (S2,  S3,  ip_stbl_result) ; 
passup_l($3,  ip_stbi_result) ; 
passdn_stbl2 (S2,  S3); 

(visibility  information 

passa r.2_2(S2,  S3,  visible_types,  visible_names)  ; 

(error  messages 

SS  .error_msgs_s  =  [ S2 . er ror_msgs_s ,  S3  ,error_msgs_s]  ; 

} 

I  GENERATE  actual_message  where  !  used  in  generators 

; 

( symbol  table 
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passio2_3  ($2,  S3,  ip_stbi_class ,  ip_stbi_names ,  ip_stbl  params) ; 
S2 . ip_stbl_resuit_i  -  SS . ip_stbi_result_i  +1 

f (SS . xref_value_i  :  S2 . actuai_text_s) ) ; 
passovr_l (S2,  S3,  ip_stbi_result ) ; 
passup_l($3,  ip_stbl_result ) ; 
passdr._stbi2  ( S2 ,  S3)  ; 

Ivisibility  information 

passdn.2_2  ( S 2 ,  S3,  visible_types,  visible_names) ; 

.'error  messages 

SS.en  =  [  S  2  .  er  ror_msgs_s ,  S3 ,error_msgs_s] ; 


) 

I 

( 

stbl_buiidO  ( ) ; 

lerror  messages 
SS .error_msgs_s  = 

) 

sends 

:  sends  send 

I 

stbl_build2 (SI,  S2); 
passdn_stbi2 (Si,  $2)  ; 

Ivisibility  information 

passdn2_2 (Si,  S2,  vi sioie_types ,  visible_names) ; 
leiror  messages 

SS.er ror_msgs_s  =  [ Si . error_msgs_s,  $2 . error_msgs_s] ; 


stbl_bui idO ( ) ; 

(error  messages 
SS  .error_msgs_s  = 


send 

:  opt iona i_f oreach  SEND  actuai_message  TO  actual_name  where 

stbi_build4 (Si,  S3,  $5,  $6)  ; 
passdr._stbI4  (SI,  S3,  S5,  S 6 ) ; 

Ivisibility  information 

passan4_2 (Si,  S3,  S5,  56,  visible_types,  visible_names) ; 

(error  messages 

SS .error_msgs_s  =  [ S 3 . e rror_msgs_s,  S5 .error_msgs_s,  S 6 . error_msgs_s 


transition 

:  TRANSITION  expression  list 


I  for  describing  state  changes 
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stbl_build:  ($2)  ; 
passdn_stb.il (S2) ; 

!visibiiity  information 

passdn_2(S2,  visible_types,  visible_names) ; 

!  error_messages 
passup_l(S2,  error_msgs) ; 

) 

I 

{ 

st£>l_buiidO  ( )  ; 

lerror  messages 
SS  ,error_msgs_s  = 

) 


forma l_mes sage 

:  opt ional_except ion  optional_formal_name  formal  arguments 

< 

SS .message_name_s  =  S2 . name_text_s; 

SS .message_f args_s  =  S3 .name_fargs_s; 

$2.args_i  =  S3 . args_text_s ; 

S2.env_i  =  MESSAGE_CLASS; 
passup_i(S2,  xref_value); 

mx_complex_decl (SS . ip_mcmxref ,  SS .d_error_s,  S2 .name_text_s, 
$2 . xref_vaiue_s/  S3 -name_f args_s) ; 


! symbol  table 
stbl_build2 (S2,  S3); 
passdn_stb!2 (S2 ,  S3); 


(visibility  information 

passio2_2 (S2,  S3,  visible_types,  visible_names) ; 

'error  mtssages 

SS.d_error_s  =  check_complex_aecl (SS . ip_mcmxref_i,  S2.name_tex 
S3 . name_f args_s,  S2.1ine_s,  SS . stbl_names_i ) ; 

SS .error_msgs_s  =  f S2 .error_msgs_s,  S3. error  msgs  s]; 


act  ua l_mes sage 

:  optionai_exceptic n  optional_actual  name  f ormal_arguments 
f 

SS . actua l_text_s  *  ( S 2 . full_name_s  ==  "") 

->  S3 . name_f args_s 
*  (S3 . name_fargs_s  ~  "") 

->  S2 . full_name_s 
*  [ S2  .  f'il l_name_s,  "(", 

S3. name  f argss, ") "] ; 


stbl_buiid2(S2,  S3); 
passdn_stbl2  (S2,  S3)  ; 

(visibility  information 
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passcr.2_2(S 2,  S3,  v i s ible_t ypes ,  visible  names); 
'error  messages 

SS .error_msgs_s  =  !$2 ,error_msgs_s,  S3 . e rror_msgs  s]; 


where 

:  WHERE  expression_list 

{ 

stbl_buildl ($2) ; 
passdn_stbll ($2) ; 

!visibility  information 

passdr._2  (S2,  visible_types,  visible_names); 

!error_mes sages 
passup_l(S2,  error_msgs); 

) 

I  tprec  SEMI  !  must  have  a  lower  precedence  than  WHERE 

f 

stbi_buiidC ( ) ; 

!error  messages 
SS  .error_msgs_s  = 

) 


optional Iy_virtual 
:  VIRTUAL 
i 

i  1 


opt  ior.a  l_except  ion 
:  EXCEPTION 

i  i 

tprec  SEMI 


operator 

:  OPERATOR  cpe rat or_I i st 

i 

passan_2(S2,  xref_value,  message  fargs) ; 
passicl_l  (S2,  ip_mcmxref)  ; 

! symbol  table 
stbl_bui!dC  ( ' ; 
passdn_stbil { S  2 ) ; 

'error  messages 
passup_i(S2,  error  rsgs); 


pas  s i cC_l (ip_mcmxref) ; 

! symbol  table 
stbl_bu_idl  ()  ; 
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SS  ,error_msgs_s  = 


opt  ional_fo reach. 

:  foreach 

( 

stbl_buildl (SI) ; 
passdn_stbll (SI)  ; 

!visibility  information 

passdn_2(Sl,  visible_types,  viaible_names) ; 

! error_messages 
passup_l(Sl,  error_msgs) ; 


stbl_buildO ( ) ; 

!error  messages 
SS .error_msgs_s  = 


foreach 

:  FOREACH  ' ('  field_list  restriction  ')' 

( 

stbi_buiid2 (S3,  S4); 
passdr._stbl2  (S3,  S4); 

(visibility  information 

pass io2_2 ( S 3 ,  S4,  visibie_types,  visible  names); 
(error  messages 

SS ,error_msgs_s  =  (S3 ,error_msgs_s,  S< .error_msgs 

) 

(  foreach  is  used  to  describe  a  set  of  messages  or  ins 

concept  s 

:  concepts  concept 

( 

passdn2_l ( S 1 ,  $2,  module_name) ; 
catmapup2_l (SI, S2, locai_types) ; 
pass io2_l ( SI , $2 ,  ip_mcmxref) ; 

(symbol  table 
stbl_build2  (31,  S2); 
passdn_stbl2  (SI,  S2); 


(visibility  information 

passdn2_2 (SI,  S2,  visibie_types,  visibie_names) ; 
(error  messages 

S S . er ror_msgs_s  =  [ S 1 . e r ror_msgs  s,  S2  .  error  msgs  s]; 


ances 
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SS . lecal_types_s  =  <(?  :  string  :  UNOEF INED_T YPE ) } ; 
passcoC_i  (ip_rtc.r-.xref)  ; 

!  syrr.bc  1  table 
stbl  buildO  ()  ; 


(errror  messages 
S5 .error_msgs_s  = 


concept 

:  CONCEPT  formal_name  type_spec  where 

!  constants 

{ 


SS . local_types_s  =  ($4 .type_name_text_s  —  SPEC_LIBRARY_MODULE_type ) 

->  f  (S2 .name_text_s  :  [ $2 . name_text_s ,  $$ . module_name_i ] )  ) 

* 

>;  (?  :  string  :  UNOEFINED_TYPE  )  j; 

passup_l(S2,  xref_vaiue) ; 

SS.d_error_s  =  check_sim.ple_deci  (SS  .  ip_mcmxref_i,  S2  .name_text_s,  $2.1ine_s 
SS . stbl_names_i) ; 

mk_simple_decl_io (SS . ip_mcmxref,  SS .d_error_s,  S 2 . nane_text_s, 

S2 . xrefva lue_s) ; 

(symbol  table 
S2.args_i  = 

S2.en.v_i  =  CONCEPT_CLASSl  ; 
stbl_build3 (S2,  S4,  S5); 
passdr._st  b  13  ( S2 ,  S  4  ,  SS); 

(visibility  information 

passdn_2(S2,  visible_types,  visibie_names) ; 
passcvr2x_2  (S2,  S<,  S5,  vrsibj.e_types,  visible_names)  ; 

(error  messages  --  incomplete  for  now... 

S S  .  e rro r_m.sgs_s  =  [  SS  .c_error_s,  S2  .  e r  ror_msgs_s,  S <  . err or_msgs_s , 

SS .error_msgs  sj; 


CONCEPT  fcrmai_name  forma l_a rgument s  where  VALUE  value_arguments  where 
(  functions,  defined  with  preconditions  and  postconditions 
t 

SS . local_types_s  -  (  (?  :  string  r  UNDEFINED_TYPE)  ); 
passup_l(S2,  xref_value); 

SS.c_error_s  «  checkcomplexdecl (SS . ip_mcmxref_i,  S2 . name_text_s , 

S3 -name_fargs_s,  S2.1ine_s,  SS.stbi_names_i); 
mk  co.mplex  decl  ( S S  .  ipir.cmxref ,  S S  . d_e r  ror_s,  S2  .  name_t ext_s , 

52 .xrefvalues,  S3 .name_fargs_s) ; 


(symbol  tacle 

S2.args_:  =  S3.args_texts; 
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passovr_l (S2,  S6,  xref_value) ; 
stbi_build5 (S2,  S3,  54,  S6,  S7); 
passdn_stb!5 ($2,  S3,  $4,  56,  S  7 ) ; 


'.visibility  information. 

passdn_2($2,  visible_types,  visible_names) ; 
passovr_2 ($2,  S3,  visible_types,  visible_names) ; 
passovr2x_2 (S3, $4, S6,  visible_types,  visible_names) ; 
passovr_2 (S6,  $7,  visible_types,  visible_names) ; 


.'error  messages 
SS .error_msgs_s 


> 


--  incomplete  for  now... 

“  [SS .d_error_a,  $2 .error_msgs_s,  $3 .error_msgs_s, 

$4 .error_msgs_s,  S6 .error_msgs_s,  S7 ,error_msgs_s] 


value_arguments  !  a  new  nonterminal  to  simplify  equations. 

:  formal_arguments 

{ 

(symbol  table 

passiol_3 ( S 1,  ip_stbl_class,  ip_stbl_names,  ip_stbl_params) ; 
passdn_l(Sl,  ip_stbl_result) ; 

SS . ip_stbl_result_s  =  (Sl.args_text_s  ==  "") 

->  SI . ip_stbl_result_s 
#  SI . ip_stbl_result_s  +| 

( ( SS . xref_value_i  : 

(  "(",  SI .  args_text_s,  ’)  "  ]  )); 


passan_stbli (SI) ; 

(visibility  information 

passiol_2  (Si,  visib,.e_types,  visible_names) ; 

! error_messages 
passup_i(Si,  error_msgs) ; 

) 

model  '  data  types  have  conceptual  models  for  values 

:  MODEL  formai^arguments  invariant 

{ 

stbl_buiid2 (S2,  S3); 
passdr._stbl2  (S2,  S3); 


(visibility  information 

passiol_2 (S2,  visible_types,  visible_names) ; 
passovr_2 (S2, S3,  visible_types,  visible_names) ; 

(error  messages 

SS -error_msgs_s  =  [ S2 . error_msgs_s ,  S3 .error_msgs_s] ; 


state  !  machines  have  conceptual  models  for  states 

:  STATE  f ormai_arguments  invariant  initially 

stbl_build3  (S2,  S3,  S 4 ) ; 
passdr._stbi3  (S2,  S3,  S4); 
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^visibility  information 

passiol_2 ($2,  visibie_types,  visible_names); 
passovr2x_2 (52, $3, S4,  visible_types,  visible_names) ; 

'.error  messages 

$5 .error_msgs_s  -  [S2  .error_msgs_s,  S3  .error_mags_a,  $4 ,error_msgs_s J 

) 

invariant  !  invariants  are  true  for  all  states  or  instances 

:  INVARIANT  express  ion _li st 

{ 

stbl_buildl ($2) ; 
passdn_stbll (S2) ; 

Ivisibility  information 

passdn_2(S2,  visible_types,  visible_names) ; 

!error_messages 
passup_l(S2,  error_msgs) ; 

) 


initially  !  initial  conditions  are  true  only  at  the  beginning 

:  INITIALLY  expression_list 

{ 

stbi_bui ldl (S2) ; 
passdn_stbll (S2)  ; 

Ivisibility  information 

passdn_2 (S2, visible_types,  vis ible_names ) ; 

■'  error_messages 
passup_i  (S2,  error  msgs); 


transactions 

:  transactions  transaction 

( 

stbl_build2  (SI,  S2); 
passdn__stol2  (Si,  S2); 

^visibility  information 

pass io2_2 (SI, S 2 , visible_t ypes ,  visible_names ) ; 
lerror  messages 

SS -error_msgs_s  =  [ SI . error_msgs_s,  S2 .error_msgs_s] ; 


stbl_bui ldO ( ) ; 

passicC_2 (visible_types,  visible_names) ; 

terror  messages 
S S . errcr_msgs  s  =  nn; 


t ransact  ion 
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:  TRANSACTION  formal_name  EQUALS  action_Iist  where 

( 

$2 . args_i  = 

52 . env_i  =  TRANS ACT ION_CLAS  S ; 

! symbol  table 
stbl_build3 (S2,  $4,  $5) ; 
passdn_stbl3 ($2,  $4,  $5); 

(visibility  information 
passdn_l (S2, visible_types) ; 

S$.d_error_s  =  check_simple_decl ( SS . visible_names_i,  S2.name  text_s, 
$2.1ine_a,  SS . stbl_names_i) ; 

mk_simple_decl (SS . visible_names_i,  SS .d_error_s,  $2 . name_text_s, 

$2 .xref_value_s,  SS . visible_names_s) ; 
passovr2x_l ($2,  S4,  S5,  visible_types) ; 
passovr2x_l (SS,  S4,  S5,  visible_names) ; 

(error  messages 

SS .error_msgs_s  =  [S2 .error_msgs_s,  S4 .error_msgs_s,  SS .error_msgs_s] 

) 

!  Transactions  are  atomic. 

(  The  where  clause  can  specify  timing  constraints. 
action_list 

:  action  list  action  %prec  SEMI  !  sequence 

( 

stbl_build2($l,  S3); 
passdn_stbl2 (SI,  S3); 

(visibility  information 

passdn2_2 (SI,  S3, visible_types,  visible_names) ; 

(error  messages 

SS .error_msgs_s  =  [ Si ,error_msgs_s,  S3 .error_msgs_s] ; 

) 

I  action 

f 

stbi_buildl (SI)  ; 
passdn_stbl 1 (S3); 

(visibility  information 

passan_2(Sl,  visible_types,  visible_names!  ; 

: e  r  r  o  r_me  s  sage  s 
passup_I (SI,  error_msgs) ; 

) 


action 

:  action  action  %prec  STAR  !  unordered  set  of  actions 

stbi_build2  (SI,  S2) ; 
passdn_stbl2 (SI,  S2); 

(visibility  information 

passdn2_2 (SI,  S2,  visible_types,  vi sible_names) ; 
(error  messages 
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a iternat 


SS .  error_msgs_s  =  ( SI . error_msgs_s,  52 .error_msgs  s]; 

} 

I  IF  alternatives  FI  !  choice 
l 

stbl_buildl (52) ; 
passdn_stbll (52) ; 

(visibility  information 

passdn_2(S2,  visible_types,  visible_names) ; 

! error_messages 
passup_l(S2,  error_msgs); 

} 

!  DO  alternatives  OD  !  repeated  choice 

( 

stbl_buildl (52) ; 
passdn_stbll ($2) ; 

[visibility  information 

passdn_2(52,  visible_types,  visible_names) ; 

! error_messages 
passup_I($2,  error_msgs) ; 

) 

actual_name  !  a  normal  message  or  subtransaction 

< 

stbl_buin-j.  (51)  ; 
passdn_stbll  (SI) ; 

(visibility  information 

passdr._2  (51,  visible_types,  visible_names)  ; 

error_messages 
passup_l(51,  error_msgs) ; 

) 

EXCEPTION  actuai_name  !  an  exception  message 

( 


stbl_buiidl (52) ; 
passdr._stbl  1  (52)  ; 

(visibility  information 

passdr._2  (S2,  visible_t.  \>es,  visible_names) ; 

'■  error_mes  sages 
passjp_l(S2,  error_msgs) ; 


1  ves 

:  alternatives  OR  guard  action_list 

( 

stbl_bui ld3 ( 51 ,  S3,  54); 
passdn_stb!3  (SI,  S3,  S4); 

'visibility  information 

passar.r_2  ( S . ,  S3,  S4,  vi  s  ible_t  ypes,  visible_names) ; 

(error  messages 

S  S  .  e  r  rcr  msgs  s  -  ;  S  _  .  e  rrormsgss,  S  3  .  error_msgs_  s ,  S4.errcr_r.sgs  s'; 
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d 


) 

I  guard  action_list 

{ 

stbl_build2 (SI,  S2); 
passdr._stbl2  ($1,  $2); 

.'visibility  information 

passdn2_2 ($1,  $2,  visible_types,  visible_namea) ; 
.'error  messages 

S$ .error_msgs_s  -  ($1 .error_msgs_s,  52 .error_msgs_s] 

) 


guard 

:  WHEN  expression  ARROW 

< 

stbl_buildl ($2) ; 
passdn_stbll (S2) ; 

(visibility  information 

passdn_2(S2,  visible_types,  visible_names) ; 

! error_messages 
passup_l (S2,  error_msgs); 

) 

I 

( 

stbl_buildO  ()  ; 

.'error  messages 
SS .error_msgs_s  = 

} 

temporals 

:  temporals  temporal 

( 

stbl_build2 (SI,  $ 2 ) ; 
passdn_si bl2  (SI,  S 2 ) ; 

(visibility  information 

passio2_2 (SI,  S2,  visible_types,  visible_names) ; 
(error  messages 

SS .error_msgs_s  =  (SI .error_msgs_s,  S2 .error_msgs_s] 

} 

I 

{ 

stbl_bui IdO  ( )  ; 

passio0_2 (visible_types,  visible_names! ; 

(error  messages 
S S . error_msgs_s  = 

i 


temporal 

:  TEMPORAL  NAME  where  response 

( 

SS . xref_va lue_s  =  get_new_xref ( S2 . % text ) ; 
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54 .  xref_value_i  *  S S . xref_value_s ; 

! symbol  table 

S3 . ip_stbl_class_i  *  SS . ip_stbl_class_i  +1 

{ (55 .xref_value_s  :  TEMPORAL_CLASS) ) ; 

S3 . ip_stbl_names_i  -  55 . ip_stbl_names_i  +| 

( (55 .xref_value_s  :  S2.%text)}; 
passovr_2 (S3,  $4,  ip_stbl_class,  ip_stbl_names) ; 
passup_2(S4,  ip_stbl_class,  ip_stbl_names) ; 
passio2_2 (S3,  54,  ip_stbl_params,  ip_stbl_result) ; 
passdn_stbl2 (S3,  $4); 

’.visibility  information 
passdn2_l (S3,  S4,  visible_types) ; 

$$.d_error_s  =  check_simple_decl (SS . visible_names_i,  S2.%text, 
S2.%line,  SS . stbl_names_i ) ; 

mk_simple_decl (SS . visible_names_i,  SS .d_error_s,  S2.%text, 

SS . xref_value_a,  SS . visible_names_s) ; 
passovr2x_l (SS,  $3,  $4,  visible_names) ; 

(error  messages 

55 . error_msgs_s  =  [ SS . d_error_s,  S3 .error_msgs_s,  S4 .error_msgs_s] 

) 

!  Temporal  events  are  trigged  at  absolute  times, 

!  in  terms  of  the  local  clock  of  the  actor. 

!  The  "where"  describes  the  triggering  conditions 
!  in  terms  of  TIME,  PERIOD,  and  DELAY. 

opt ionai_formal_name 
:  formal_name 
( 

passup_3(Si,  narae_params,  name_text,  line); 
passdr._2  (SI,  args,  env)  ; 
passup_l(Si,  xref_value) ; 

(symbol  table 
stbi_buildl  (SI)  ; 
passdr._stbll  (Si)  ; 


(visibility  information 

passiol_2 (SI,  visible_types,  visibie_names) ; 


(error  messages 
passup_l (SI,  error_msgs); 

( 

SS.line_s  -  -1; 

SS . name_pa rams_s  1 
SS . name_text_s  = 

S S . xrefva iue_s  =  get_new_xre f { S S . args_i ) ; 

(symbol  table 

ado_elem (SS . ip_stbl_class_i,  SS .xref_value_s,  SS.env_i,  SS.ip_stbl 
add_eiem(SS. :p_stbl_naraes_i,  SS . xref_vaiue_s, SS.args_i,  SS. ip_stbi 
passioC_2 (ip_stbl_params,  ip_stbl_result ) ; 


class_s) 
names  s) 
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!visibility  information 

passio0_2 (visible_types,  visible_names) ; 

lerror  messages 
$$ .error_msgs_s  = 


) 


formal_name 

:  NAME  formal_parameters 

( 

SS . line_s  -  Sl.lline; 

SS .name_text_s  *  Sl.%text; 
passup_l ($2,  name_params) ; 

SS ,xref_value_s  *  get_new_xref (SI .%text) ; 

! symbol  table 

SS . signature_s  =  (  S$.args_i  --  "") 

—  >  n  " 

*  SS.args_i,  *)"  ); 

add_elem(SS .ip_stbl_class_i,  SS . xref_value_s,  $S.env_i,  $2 . ip_stbl_class_i 
add_elem (SS . ip_stbl_names_i,  SS . xref_value_s, 

Sl.%text  A  SS . signature_s,  S2 . ip_stbl_names_i) ; 
add_elem (SS . ip_stbl_params_i,  SS .xref_value_s,  S2 . name_params_s, 

S2 . ip_stbl_params_i) ; 
passdn_l(S2,  ip_stbl_result) ; 

passup_4 (S2,  ip__stbl_class,  ip_stbl_names,  ip_stbl_params,  ip_stbl_result ) 
passdn_stbll ($2)  ; 

!  visibility  information 

passiol_2 (S2,  visible_types,  visible_names) ; 

(error  messages. 
passup_l(S2,  error_msgs); 


f orma i_parameters  !  parameter  values  are  determined  at  specification  time 

:  '('  field_list  ')'  where 

; 

S$ . name_params_s  =  S2 . f ieldpattern_s; 

(symbol  table 
stbi_build2 (S2,  54); 
passdn_stbl2  (S2,  S4); 


!  visibility  information 

passiol_2 ($2,  visible_types,  visible_names) ; 
passovr_2 (S2,  S4,  visible_types,  visible_names) ; 

(error  messages. 

SS ,error_msgs_s  =  (S2 .error_msgs_s,  $4 .error_msgs_s j ; 


SS .name_params_s  =  NULL_STRING; 

(symbol  table 
stbl  buildCO; 
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Ivisibility  information 

passio0_2 ( visible_types,  visible_names) ; 

I  error  messages 
SS .error_msgs  s  = 


f ormal_arguments  !  arguments  are  evaluated  at  run-time 

:  '  ('  f ield_list  '  )  ' 

{ 

$S .name_fargs_s  -  S2 . f ieldpattern_s; 

SS .  args_text_s  =  S2.text_s; 

! symbol  table 
stbi_bui ldl  ($2) ; 
passdn_stbll  { $2 ) ; 

Ivisibility  information 

passiol_2 (S2 ,  visibie_types,  visible_names) ; 

lerror  messages 
passup_l(S2,  error_msgs) ; 


SS . name_fargs_s  = 
SS . args_text_s  * 

! symbol  table 
stbl_bui ldO ( ) ; 


Ivisibility  information 

passioC_2 (visible_types,  visible  names); 

'error  messages 
SS .errormsgss  =  ""; 


f ield_list 

:  fieidlist  field 

{ 

SS.fieidpatterr._s  =  [SI .  fieldpattern_s,  ELEM_DELIMITER, 
S3 . f ieldpattern_s] ; 

SS .texts  =  [Sl.texts,  ",  ",  $3.text_s]; 

Isymbol  table 

stbl_build2  (SI,  S3); 
passdr._stbi2  (SI,  S3); 

Ivisibility  information. 

passio2_2 (S.,  S3,  visible_types,  visible_names) ; 
lerror  messages 

SS ,error_msgs_s  =  '  S 1 . e rror_msgs_s ,  S3 .error_msgs_s ] ; 
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passup_2(Sl,  f ieldpattern,  text); 


!_ymr>ol  table 
stbl^buiidi (SI)  ; 
passdn_stbll (SI) ; 

(visibility  information 

passiol_2 (SI,  visible_types,  visible_names) ; 

(error  messages 
passup_l(Sl,  error_msgs) ; 


field 

:  declname_list  type_spec 

{ 

SI .name_type_text_i  ■=  S3  .  type_name_text_s; 

SS.text_s  =  [Sl.text_s,  "  :  ",  S3 . type_name_text  s]; 

$1 . name_tyoe_value_i  =  S3 . type_name_value  s; 
passup_l (SI,  f ieldpattern)  ; 

(symbol  table 
stbl_build2 (SI,  S3) ; 
passdn_stbl2  (SI,  S3); 

(visibility  information. 

passioi_2 (SI,  visible_types,  visible_names) ; 
passdn_2 (S3,  visible_types,  visible_names) ; 

(error  messages 

SS .error_msgs_s  *  (SI .error_msgs  s,  S3 .error_msgs_s] ; 

) 

!  'S'  NAME  ':'  typespec 

( 

SS. f'el dp a tte”_s  =  ["S",  S2.%text,  " : " , SS . type_name_vaiue_s  j; 

S$.text_s  =  ("S",  S2.%text,  "  :  ",  SS .type_name_text_s ] ; 

(symbol  table 

SS .xref_value_s  =  get_new_xref ($2 . Itext) ; 

add_elem ( SS . ip_stbl_class_i ,  SS ,xref_value_s,  VARI ABLE_CLASS , 

S  S . ip_stbl_cla  s  s_i ) ; 

add_elem (SS . ip_stbl_names_i,  SS . xref_va lue_s,  "S" "S2 . %text , 

SS . ip_stbl_names_i) ; 

add_e lem ( S S . ip_stbl_resu lt_i ,  SS .xref_value_s,  SS . type_name_value  s, 

SS . ip_stbl_result_i) ; 
passdn_l($S,  ip_stbl_params) ; 

passup_S(SS,  ip_stbl_class,  ip_stbl_names,  ip_stbl_result ,  ip_stbl_params) 
passdn_stbll (SS) ; 

(visibility  information 

SS . visible_types_s  =  (SS -type_name_value_s  ==  SPEC_L IBRAR Y_MODULE_t  ype ) 

->  SS . visible_types_i  +1 
(  (S2 .  %text  :  [S2.»text, 

" _ local"  ] )  } 

*  SS . visible_types_i; 

SS.d_error_s  =  check_simple_decl  (SS  .  visible_r  nes_i  ,  $2.%text, 

S2. %iir.e,  SS.sccl  names  i )  ; 
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mx_s imple_decl_io ( $S . visible_name s ,  SS . d_error_s,  S2.%text,  SS . xref_value_s) 
passar._l(S4,  visible_types) ; 
passovr_l ( SS ,  S4,  visible_names) ; 

lerrcr  messages 

SS  .err or_msgs_s  =  !  SS .d_error_s ,  $4 . error_msgs_s]  ; 

} 

I  QUEST ION_MARX 

{ 

SS . f ieldpattern_s  = 

SS  .  text_s  -  ■?“; 

! symbol  table 
stbl  buildO  ()  ; 


(visibility  information 
passioO_l (visible_types) ; 


lerror  messages 

SS .error_msgs_s  =  error_message (UNRESOLVED_TYPE,  $l.%line); 


type_spec 

:  actual_name  !  name  of  a  data  type 

{ 

SS  .  type_name_text_s  =  Sl.actual__name_text_s; 

SS .type_name_value_s  =  SS . vis ibie_types_i  (S 1 . actual_name_text_s) ; 

! symbol  table 
stbl_builcl  (SI) ; 
pas'd-  stb ' I  (S  i )  ; 


(visibility  information 

passdn_2(51,  visrbie_types,  visibie_names) ; 


lerror  messages 

SS.tn.p_r.se  -  error_message (UNDECLARED_TYPE,  Sl.line_s, 

SI .actual_name_text_s) ; 

S S  .  e r  ro r_rr.sgs_s  =  (SS  .  visible_types_i  (S 1 .  actual_name_text_s )  == 

un’qef:ned_type) 

->  SS.tmp_msg 

# 

QUEST ION_KARK 

/ 

SS . typenanetexts  = 

SS  . type_r.ame_va iue_s  = 

' symbol  table 

stci_bgiidS ( ) ; 

lerror  messages 

SS ,error_msgs_s  =  e r ror_nessage (UNRESOLVED_TYPE ,  $l.%line); 
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!  This  structure  was  added  so  that  a  name  list  used  for  declarative 
!  purposes  (e.g.  in  a  field)  could  be  easily  distinguished  from  a  name  list 
!  used  ir.  an  applicative  structure  (e.g.  imports,  export,  hide). 

This  lessened  the  actual  attribute  load  of  the  narae_list  structure. 
aeclname_list 

:  declname_list  NAME 
{ 

SS . xref_value_s  -  get_new_*ref (S2 .  %text); 

$$.text_s  -  [$l.text_s,  "  ",  S2.ttext]; 
passdn_2($l,  name_type_value,  name_type_text ) ; 

SS . f ieldpattern_s  »  (  $1 . f ieldpattern_s,  ELEM_0ELIMITER, 

S2.%text,  SS .name_type_value_i  ]; 


(symbol  table 

passdn_4(Sl,  ip_stbl_class,  ip_stbl_names,  ip_stbl_result,  ip_stbl_params); 
add_elem ( $1 . ip_stbl_class_s,  SS . xref_value_s,  VARIABLE_CLASS, 

SS . ip_stbl_class_s) ; 

add_e' »m ($1 . ip_stbl_names_s,  SS .xref_value_s,  S2.%text,  SS . ip_stbl_names_s) 
add_elem(Sl . ip_stbl_result_s,  SS .xref_value_s,  SS .name_type_value_i, 

SS . ip_stbl_result_s) ; 
passup_l(Sl,  ip_stbl_params) ; 
passdn_stbll (SI) ; 

(visibility  information 

passdn_2($l,  visible_types,  visible_names) ; 

SS.d_error_s  =  check_simple_decl (SI . visible_names_s,  S2.%text, 

S2.%line,  SS . stbl_names_i) ; 

nk_simple_decl (SI . visible_names_s,  SS .d_error_s,  S2.%text, 

SS .xref_value_s,  SS . visible_names_s) ; 

SS  .  vis ible_types_s  -  (SS  . name_type_text_i  — >  SPEC_LIBRARY_MODUl.E_type) 

->  SI.  visible_types_s  +| 

(  (S2 .  %text  :  [$2.%text, 

" _ local"  3 )  ! 

#  SI . visible_types_s; 

SS ,error_msgs_s  *  [ S 1 . error_msgs_s,  SS .d_error_s] ; 

) 

I  NAME 

S S . xref_value_s  =  get_new_xre f ( S 1 .  %text) ; 

S S . f ieidpattern_s  =  (Sl.%text,  S S . name_type_va lue_i ] ; 

SS.text_s  =  $l,%text; 

(symbol  table 

add_eiem ( SS . ip_stbl_c 1  a s s_i ,  SS . xref_value_s,  VARIABLE_CLASS, 

SS . ip_stbl_class_s) ; 

add_elem(SS . ip_stbl_names_i,  SS . xref_value_s,  Sl.ttext,  SS . ip_stbl_names_s) 
add_elem (SS . ip_stbl_result_i,  SS . xref_value_s,  SS . name_type_value_i, 

SS . ip_stbl_result_s) ; 
passioO_l ( ip_stbl_params) ; 


(visibility  information 

;  —  eventually  need  to  make  local  with  module  name... 

SS . visible_types_s  =  (SS ,name_type_text_i  ==  SPEC_LIBRARY_MODULE_type) 
->  SS.  visibie_types_i  +i 
f  (SI . %text  :  |S1 . »text, 

" _ local"  ] )  ) 

*  SS . visit let ypesi ; 
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S$.d_error_s  =  check_s impie_decl ( $$ . visible_names 
Sl.%line,  S S . stbl_names_i ) ; 
mk_simple_deci_io (SS . visibie_names,  $$.d  error  s, 
SS . xref_value_s) ; 

SS  . error_msgs_s  =  S S . d_error_s ; 

1 


name_list 

:  name_list  NAME 

{  t 

I  NAME 

{  ) 


opt  ior.ai_actual_name 
:  actuai_name 

{ 

passup_4(Sl,  actual_name_text,  actuai_params,  full 

stbl_buildl (SI) ; 
pasadn_stbll (Si) ; 

(visibility  information 

passdr._2  ( S 1 ,  visible_types,  visible_names)  ; 

(errcr_nessages 
passup_l($l,  error_msgs); 


SS.lir.e_s  =  -1; 

SS . actual_name_text_s  = 
S S  .  actuai_params_s  = 

SS  .  fuii_r.ame_s  = 

stbi_buiidC  ()  ; 

(error  messages 
SS ,errcr_msgs  s  = 


actual_name 

:  NAME  act ua .^parameter s 

( 

SS  .  actua  l_r,ame_text_s  =  Si.»text; 

SS.iir.e_s  =  Sl.lline; 
pass-p_l(S2,  actuaiparams); 

SS  .  f - _r.ame_s  =  ( S2 . act ua i_pa r ams_s  =  =  "") 

->  Si.  %text 

#  [Sl.ltext,  S2 . actual_params_s. 


(symnci  taoie 
stbl_buildi ( S2 ) ; 
passdr.  stfci  1  ( S 2 )  ; 


i,  Sl.%text, 
S 1 . %text , 


name,  line) 
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Ivisibiiity  information 

passdn_2(S2,  visible_types,  visible_names) ; 

'  error_messages 
passup_l(S2,  error_msgs) ; 


actual_parameters  !  parameter  values  are  determined  at  specification  time 

:  ' arg_list  ' )' 
f 

SS . actual_params_s  =  S2 . arglist_text_s; 

stbl_buildl  (S2) ; 
passdn_stbll ($2) ; 

Ivisibility  information 

passdn_2(S2,  visible_types,  visible_names) ; 

! error_mes sages 
passup_l(S2,  error_msgs) ; 

) 

I  %prec  SEMI  !  must  have  a  lower  precedence  than  ’  (' 

< 

SS . actual_params_s  = 

stbl_buildO  ( ) ; 

! error  messages 
SS .error_msgs_s  = 


actuai_arguments  !  arguments  are  evaluated  at  run-time 

:  '  ('  arg  list  '  )  ' 


SS . f uli_args_s  =  (S2 . argl ist_text_s  == 

->  "" 

*  S2.arglist  text  s, 


stbi_buildl  ( S 2 )  ; 
passdr,_stbll  (S2)  ; 


!visibility  information 

passdr._2(S2,  visible_types,  visible_names)  ; 


( 


!error_messages 
passup_l(S2,  error_msgs) ; 

%prec  SEMI  !  must  have  a  lower  precedence  than  '  (’ 

stbl  bui ldC ( ) ; 


’error  messages 
SS  .error_msgs_s  - 


a  rc_ list 

:  a rg_ list  arg  %prec  COMMA 
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SS ,arglist_text_s  =  ;  Si  .  argiist_text_s,  ACTUA1._DELIM,  S3. a 

stbi_build2 (Si,  S3); 
passdn._stbi2  (SI,  S3)  ; 

(visibility  information 

passdn.2_2  ( Si ,  S3,  visible_types,  visible_names) ; 

(error  messages 
SS . error_msgs_s  = 

! 

I  arg 

{ 

$$.argiist_text_s 

stbl_buiidi (SI) ; 
passdn_stbil (SI) ; 

(visibility  information 

passdn_2($l,  visible_types,  visible_names)  ; 

!errcr_messages 
passup_l (Si,  error_msgs) ; 


(Si  .  error_msgs_s,  S3 .error_msgs  s]; 


=  S 1 .  a rg_text_s; 


arc 

;  expression 

SS  .  arg_tex;_s  =  S 1 .  xt  er._t  ype_s; 

stbi_buildl (Si) ; 
passdr._stfcii  (Si)  ; 

(visibility  information 

passan_2(Si,  visibie_types,  vi sible_names ) ; 

( error_messageo 
passup_l (SI,  error_msgs) ; 


SS.arg_text_s  ~  S*.xten.  type  s; 

st  bl_bu i idi  (Si)  ; 
passor._stol  1  (Si)  ; 

(visibility  information 

passdrs_2(Sl,  visibie_types,  visible_names); 

! err or_mes sages 
passup_l($l,  error_msgs); 


express .  or._  list 

:  express . cr._ . i st  expression.  Iprec  COMMA 

a.,  types  in.  an.  expression,  list  must  be  the  same 
SS.x-.er_f/pc  s  =  Si.xrer.  type  s; 


g_tex 
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stbl_build2 (Si,  S3); 
passdn_stb!2 ( S 1 ,  S3); 

'visibility  information 

passd.-.2_2  (SI,  S3,  vis ible_types ,  visible_names) ; 

(error  messages 

$S  .error__msgs_s  =  [$1  ,error_msgs_s,  S3  ,error_msgs_s] ; 

) 

I  expression  Iprec  COMMA 

1 

passup_l($l,  xten_type) ; 

stbl_buildl (SI) ; 
passdn_stbll (SI) ; 

(visibility  information 

passdn_2(Sl,  visible_types,  visible_names) ; 

!error_mes sages 
passup_l(Si,  error_msgs) ; 

) 


expression 

:  quantifier  '('  fieid_list  restriction  BIND  expression  ')' 

< 

SS  .xter._type_s  =  ":boolean"; 

stbl_build3  (S3,  S4,  S 6 )  ; 
passdn_stb!3  (S3,  $4,  S6) ; 

(visibility  information 

passdr.3_2  (S3,  S4,  S6,  visible_types,  visible_names)  ; 

(error  messages 

SS  .error_msgs_s  =  (S3  .error_msgs_s,  S 4  . error_msgs_s ,  $6 ,error_msgs_s 

:• 

i  actual_name  actual_argumer.ts 

SS  . xten_type_s  =  [REF_SYMBOL,  S 1 .  ful I_r,ame_s ,  $2  .  f u 1 l_args_s ( ; 

stbl_build2  (51,  S2!  ; 
passdn_stbl  (SI,  S  2 ) ; 

(visibility  information 

passdn2_2  (SI,  S2,  visible_types,  visible_names) ; 

(error  messages 

SS . error_msgs_s  =  [ S 1 . error_msgs  s,  52 .error_msgs_s] ; 

) 

i  actuai_name  actual_name  actual^arguments 

( 

SS . xten_type_s  =  [REF_SYMBOL,  SI . full_name_s,  S3 . full_name_s, 

S4 . f u 1 l_args_s ] ; 


stbl_build3 (SI,  S3,  S4); 
passdn  stbl 3  (SI ,  S3,  S 4 ;  ; 
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(visibility  information 

passdr.3_2  ( SI ,  S3,  S4,  visible_types,  visible_names) ; 

lerror  messages 
SS . e r ror_msgs_s 

I  NOT  expression 

< 

SS .xten_type_s  = 

stbl_buiidl ( S  2 ) ; 
passdr._st bli  ( S2 )  ; 

Ivisibiiity  information 

passdn_2(S2,  visible_types,  viaible_names); 

!error_messages 
passup_l(S2,  error_msgs); 

) 

I  expression  AND  expression  %prec  AND 

< 

SS . xten_type_s  =  (REF_SYM3CL,  S2.%text,  SI .xten_type_s, 

ACTUAL_DE1IM, S3 . xt en_t ype_s,  ")"  ]; 

stbl_build2 (SI,  S3); 
passdn_stb!2 (SI,  S3); 

Ivisibiiity  information 

passdr.2_2  (SI,  S3,  visible_types,  visible_names) ; 

'error  messages 

SS  .error_msgs_s  =  [SI  .errcr_msgs_s,  $3  .error_msgs_s]  ; 

} 

expression  OR  expression  tprec  OR 

f 

SS  .  xter._type_s  =  [REF_SYM30L,  $2.*text,  "(",  S 1 .  xter._t  ype_s , 
ACTu'AL_DELIM,  S3  .  xten_type_s,  ")"  )1 

stbi_boiid2 (Si,  S3); 
passdr_stti2  (SI,  S3); 

Ivisibiiity  information 

passdr.2_2  ( S i ,  S3,  visibie_types,  visibie_names)  ; 
lerror  messages 

SS .error_msgs_s  =  [ Si .errcr_msgs_s,  S3 .error_msgs_s] ; 

) 

!  expression  IMPLIES  expression  %prec  IMPLIES 

i 

SS . xten_type_s  =  (REF_SYMBOL,  S2.%text,  "(",  S 1 . xten_type_s , 
ACT"JAL_DELIM,  S3  . xt en_t ype_s ,  ")"  ]; 

stbi_bw,i  id2  (Si,  S3); 
passdr._stb!2  (S  I ,  S3); 

'visibility  information 

passor.2_2  (  S I ,  S3,  visib.e_types,  vi s ibie_names )  ; 
error  messages 

SS. error  msgss  -  [ Si .error  msas  s,  S 3  .  er r ormsgs  s  [  ; 


=  [SI .error_msgs_s,  S3 . e rror_msgs_s ,  $4 . error_msgs_s 
%prec  NOT 

[REF_S YMBOL,  Sl.ltext,  "(",  $2 .xten_type_s,  *)"]; 
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tprec  IFF 


) 

I  expression  IFF  expression 

( 

$$ .xten_type_s  =  (R£F_SYMBOL,  $2.ttext,  *(»,  $1 ,xten_type_s, 
ACTUAL_DELIM, $3 . xten_type_s,  *)"  ]; 

stbl_build2 (SI,  S3) ; 
passdn_stbl2 (SI,  S3) ; 

(visibility  information 

passdn2_2 (SI,  S3,  visible_types,  visible_names) ; 

(error  messages 

SS .error_msgs_s  *  [SI -error_msgs  s,  $3 .error_msgs  s) ; 

) 

I  expression  LT  expression  tprec  LE 

{ 

SS.xten_type_s  =  [REF_SYMBOL,  "<"  ,  ■(",  $1 ,xten_type_s, 
ACTUAL_DELIM, S3 .xten_type_s,  ")■  ]; 

stbl_build2 ($1,  S3); 
passdn_stbl2 (SI,  S3); 

(visibility  information 

passdn2_2 ( S 1 ,  S3,  visible_types,  visible_names) ; 

(error  messages 

SS -error_msgs_s  =  ( S 1 .error_msgs_s,  S3 .error_msgs  s] ; 

) 

expression  GT  expression  tprec  LE 

f 

SS . xter._type_s  -  (REF_SYMBOL,  ">",  "(",  SI  .xten  type  s, 
ACTUAL_DELIM, S3 .xten_type_s,  ")"  ); 

stbl_build2 (SI,  S3); 
passdr,_stbl2  (SI,  S3); 

(visibility  information 

passdn2_2 ( S 1 ,  S3,  visibie_types ,  visible_names) ; 

(error  messages 

SS ,error_msgs_s  =  [SI .error_msgs_s,  S 3 . error_msgs_s ) ; 

! 

expression  EQUALS  expression  tprec  LE 

[ 

SS ,xten_type_s  -  [REF_SYMBOL,  "(",  S 1 . xt en_type_s , 

ACTUAL_DELIM,  S3  .  xter._t  ype_s ,  ")"  1; 

stbl_build2 ($1,  S3); 
passdr._stb!2  (SI,  S3); 

(visibility  information 

passdn2_2 ( S 1 ,  S3,  visibie_types,  visible_names) ; 

(error  messages 

SS .error_msgs_s  =  (SI .error_msgs_s,  S3 .error_msgs_s ] ; 

expression  LE  expression  tprec  LE 

( 

SS.xten_type_.  =  ( REF_S YMBOL,  S2.ttext,  "(",  S 1 . xten_t ype_s , 
ACTUAL_DELIK,  S3  . xter._type_s,  ")"  ]; 
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stbl_build2 (Si,  S3); 
passdn_stbl2  (Si,  S3); 

(visibility  information 

passdn2_2 (SI,  $3,  visible_types,  visible_names) ; 

(error  messages 

SS  . error_msgs_s  -  [SI. error  c,*;?  s,  $3 .error_msgs_*l  ; 

1 

I  expression  GE  expression  %prec  LE 

{ 

SS.xten_type_s  =  [REF_SYMBOL,  S2.*text,  *(",  $1 . xten_type_s 
ACTUAL_DELIM, S3 . xten_t ype_s,  ")"  ]; 

stbl_build2 (SI,  S3); 
passdn_stbi2 (SI,  S3); 

(visibility  information 

passdn2_2 (SI,  S3,  visible_types,  visible_names) ; 

(error  messages 

SS .error_msgs_s  =  ( SI . error_msgs_s ,  S3. error  msgs  s); 

! 

expression  NE  expression  tprec  LE 

( 

SS.xt,  t_type_s  =  [REF_S YMBOL,  S2.%text,  "(",  SI .  xten_type_s 
ACT'JAL_DELIM,  $3  . xten_type_s,  ")"  ]; 

stbl_buiid2 (Si,  S3); 
passdn_stb!2 (S 1 ,  S3); 

(visibility  information 

passdr.2_2  (SI,  S3,  visibie_types,  visible  names); 

(error  messages 

SS  .error_msgs_s  =  (SI  .error_msgs_s,  S3. error  msgs  sj; 

i 

expression  NLT  expression  %prec  LE 

( 

SS .xter_type_s  =  (REF_SYM30L,  S2.»text,  "(",  S 1 . xten_t ypes, 
ACT'JAL_DELIM,  S3  .  xten_type_s,  ")"  ]; 

stbl_build2 (SI,  S3) ; 
passa'_stb!2  (Si,  S3) ; 

(visibility  information 

passdn2_2  (Si,  S3,  visible_types ,  visible_names) ; 

(error  messages 

SS . errcr_msgs_s  -  [ Si . e rror_msgs_s ,  S3 . error_msgs_s ] ; 

expression  NGT  expression  %prec  LE 

SS.xten_type_s  =  [REF_SYMBOL,  S2.%text,  "(",  SI .xten_type_s, 
ACTL'AL_DELIM,  $3  .xten_type_s,  ")"  ]; 


stb:_buiid2  (SI,  S3); 
passdn_stbi2  (Si,  S3)  ; 

•  visibility  ir.fcrrat  icr. 


159 


passdn2_2  (SI ,  S3,  visible_types,  visible_names) ; 

(error  messages 

SS .error_msgs_s  *  ( S 1 . error_msgs_s,  S3 ,error_msgs_s] ; 

) 

I  expression  NLE  expression  %prec  LE 

{ 

$$ .xten_type_s  “  [R£F_SYMBOL,  $2.%text,  ■(",  $1 ,xten_type_s, 
ACTUAL_DELIM, S3 . xten_type_s,  *)"  ]; 

atbl_build2 (SI,  S3) ; 
passdn_stbl2 (SI,  S3); 

(visibility  information 

passdn2_2 (SI,  S3,  viaible_types,  vlsible_names) ; 

(error  messages 

SS .error_msgs_s  *  [SI .error_msgs_s,  S3 .error_msgs_s] ; 

> 

|  expression  NGE  expression  %prec  LE 

( 

SS . xten_type_s  =  [REF_SYMBOL,  S2.%text,  *(",  SI .xten_type_s, 
ACTUAL_DELIM, S3 . xten_type_5,  •)"  ]; 

stbl_build2 (SI,  S3)  ; 
passdn_stbl2 (SI,  S3); 

(visibility  information 

passdn2_2 (SI ,  S3,  visible_types,  visible_names) ; 

(error  messages 

SS .error_msgs_s  =  [ S 1 .error_msgs_s,  S3 .error_msgs_s] ; 

) 

I  expression  EQV  expression  %prec  LE 

( 

SS  .  xter._type_s  =  [REF_SYMBOL,  S2.%text,  "(",  S 1 .  xten_type_s, 
ACTUAL_DELIM, S3 . xten_type_s,  ")"  ]; 

stbl_build2 (SI,  S3); 
passdn_stbl2 (SI,  S3); 

(visibility  information 

passdr.2_2  (SI,  S3,  visible_types,  visible_names)  ; 

(error  messages 

SS -error_msgs_s  =  [ S 1 . error_msgs_s,  S3  .error_msgs_s]  ; 

) 

I  expression  NEQV  expression  %prec  LE 

( 

SS . xten_type_s  =  [REF_SYMBOL,  S2.ttext,  "(",  SI .xten_type_s, 
ACTUAL_DELIM, S 3 . xten_t ype_s,  ")"  ); 

stbl_build2 (SI,  S3); 
passar._stbl2  (Si,  S3); 

(visibility  information 

passdn2_2 (Si,  S3,  visible_types,  visible_names) ; 

(error  messages 

SS . error_msgs_s  *  ( S 1 . er ror_msgs_s ,  S3 . e rror_msgs_s ] ; 
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tprec  UMINUS 


MINUSMARX  expression 

( 

SS . xten_type_s  =  [REF_SYMBCL,  *(“,  S2 . xten_type_s. 


stbl_bui ldl (52) ; 
passdn_stbll (52) ; 


(visibility  information 

passdn_2(S2,  visible_types,  visible_names) ; 

!error_mes sages 
passup_l(S2,  error_msgs) ; 

1 

expression  PLUSMARK  expression  tprec  PLUS 

( 

55 . xten_type_s  =  [REF_SYMBOL,  ■+",  *(*,  51 .xten_type_s 
ACTUAL_DELIM,  S3 . xten_type_s,  *)"  ]; 

stbl_build2  ($1.  S3); 
passdn_stbl2  (51,  S3); 

(visibility  information 

passdn2_2 (51,  S3,  visible_types,  visible_names) ; 

(error  messages 

55. error  msgs_s  =  [51. error  msgs  s,  S3 .error_msgs_s] ; 

) 

expression  MINUSMARK  expression  %prec  MINUS 

( 

55 . xten_type_s  *  [REF_SYMBOL,  "(",  5 1 . xten_type_s 

ACTUAL_DELIM, S3 . xten_type_s,  ")"  ] ; 

stbl_build2  (51,  S3); 
passar._stbl2  (51,  S3); 

(visibility  information 

passdn2_2 (51,  S3,  visible_types,  visible_names) ; 

(error  messages 

55 ,error_msgs_s  »  ( 5 1 . error_msgs_s,  S3 . error_msgs_s ] ; 

) 

expression  STARMARK  expression  %prec  MUL 

i 

55 . xten_type_s  ~  [REF_SYMBOL,  "(",  51 .xten_type_s 

ACTUAL_DELIM, S3 . xten_type_s,  ")"  ]; 

stbl_build2  (51,  S3); 
passdn_stbl2 (51,  S3); 

(visibility  information 

passdn2_2  (51,  S3,  visible_types,  visible_names) ; 

(error  messages 

55 ,error_msgs_s  =  [ 5 1 . error_msgs_s,  S3 . error_msgs_s ] ; 

expression  SLASH  expression  tprec  DIV 

< 

SS  .  xten_type_s  =  [REF_SYMBOL,  "/",  "C,  5 1 .  xten_type_s 
ACTUALSELIM,  S3  .  xter.types,  ")" 
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stbl_build2  (SI,  S3); 
passdn_stbl2  (SI,  S3); 

Ivisibility  information 

passdn2_2 (SI ,  S3,  visible_types,  visible_names) ; 

[error  messages 

$$ ,error_msgs_s  *  [SI .error_msgs_s,  S3 ,error_msgs_s] ; 

) 

I  expression  MOD  expression  %prec  MOD 

( 

SS .xten_type_s  »  [R£F_SYMBOL,  S2.%text,  *(",  51 ,xten_type_a, 
ACTUAL_DELIM, S3 . xten_type_s,  *)■  ]; 

stbl_build2 (SI,  S3); 
passdn_stbl2 (SI,  S3); 

Ivisibility  information 

passdn2_2 ($1 ,  S3,  visible_types,  visible_names) ; 

[error  messages 

SS -error_msgs_s  =  [SI .error_msgs_s,  S3 .error_msgs_s] ; 

) 

I  expression  EXP  expression  tprec  EXP 

( 

SS . xten_type_s  =  [REF_S YMBOL,  S2.%text,  "(",  S 1 . xten_type_s , 
ACTUAL_DELIM, S3 .xten_type_s,  ")"  J; 

stbl_build2 (SI,  S3); 
passdn_stbl2 (SI,  S3); 

[visibility  information 

passdn2_2 (SI,  S3,  visible_types,  visible_names)  ; 

[error  messages 

SS ,error_msgs_s  =  [SI -error_msgs_s,  S3 ,error_msgs_sJ ; 

! 

I  expression  U  expression  %prec  U 

[ 

SS . xtentypes  =  [REF_SYMBCL,  S2.%text,  "(",  Si.xten  type_s, 
ACTUAL_DELIM, S3 . xten_Lype_s,  ")"  ]; 

stbl_build2 (Si,  S3); 
passdn_stb!2 (SI ,  S3); 

[visibility  information 

passdn2_2 (SI,  S3,  visible_types,  visible_names) ; 

[error  messages 

SS  .error_msgs_s  -  [  S 1 . error_msgs_s ,  S3  . error_msgs_s ] ; 

j 

!  expression  APPEND  expression  Iprec  APPEND 

I 

SS . xten_type_s  =  [REF_SYMBOL,  S2.ttext,  "(",  SI .xten_type_s, 
ACTUAi,_DELIM,  S3  .  xt  en_type_s ,  ")"  ]; 

stbl_build2 (Si,  S3) ; 
passdr._stbl2  (SI,  S3); 

[visibility  ir.  format  ic-. 
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passdn2_2 (SI,  S3,  visibie_types,  visible_names) ; 
ierror  messages 

SS . error_msgs_s  =  [ S 1 . error_msgs_s,  S3  ,error_msgs  s) ; 

) 

i  expression  IN  expression  %prec  IN 

( 

SS.xten_type_s  *  (REE_SYMBOL,  S2.»text,  *(■,  $1 .xten_type_s, 
ACTUAL_DEI.IM,  S3  .xten_type_s,  ")*  ]; 

»tbl_build2(Sl,  S3) ; 
passdn_stbl2 ($1,  S3); 

ivisibility  information 

passan2_2 (SI,  S3,  visible_types,  visible_names) ; 
lerror  messages 

SS .error_msgs_s  =  [SI .error_msgs_s,  S3 ,error_msgs_s) ; 

1 

I  STARMARK  expression  iprec  STAR 

!  *x  is  the  value  of  x  in  the  previous  state 

i 

SS . xten_type_s  =  S2 .xten_type_s; 

stbl_buildl (S2) ; 
passdn_stbll (S2)  ; 

ivisibility  information 

passdn_2(S2,  visible_types,  visible_names) ; 

!  error_mes sages 
passup_l(S2,  error_msgs) ; 

I  'S'  expression  fcprec  DOT 

!  Sx  represents  a  collection  of  items  rather  than  just  one 
■  s-  =  (x,  Ss2)  means  si  =  union ({x),  s2) 
s-  =  [x,  Ss2j  means  si  =  append! [x],  s2) 

SS . xtentypes  =  S2 . xten_type_s ; 

stbl_buildl ( S  2 )  ; 
pa ssdr._stb  1 1  ( S 2 )  ; 

ivisibility  information 

passdr._2  (S2,  visiole_types,  visibie_names)  ; 

!  error_mes sages 
passup_l (S2,  error_msgs); 

expression  RANGE  expression  »prec  RANGE 

!  x  in  ;a  ..  b]  iff  x  in  {a  ..  b)  iff  a  <=  x  <-  b 
>d  • •  b’  is  sorted  in  increasing  order 


SS  .  xter.types  *  1  REF  _S  YMBCL,  S2.%text,  "(",  S 1 .  xten_type_s , 
ACTUAi._DELIK,  S3  .xten_type_s,  ")"  ]; 

stb:_buiid2  (SI,  S3); 
passdr._stb!2  (SI ,  S3); 
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Ivisibility  information 

passdr.2  -'(SI,  S3,  visible_types,  visible_names)  ; 

(error  messages 

SS  . error_msgs_s  «■  [ SI . error_msgs_s,  $3  .error_msgs_s] ; 

) 

|  expression  DOTMARK  NAME  %prec  DOT 
f 

SS.xten  type  s  -  [R£F_SYMBOL,  *(",  $1  ,xten_type_s, 

ACTUAL  DELIM,  S3 . %text , ’ .  *)■]; 


stbl_buildl (SI) ; 
passdn_stbll (SI)  ; 

Ivisibility  information 

passdn_2(Sl,  visible_types,  visible_names)  ; 

! error_messages 
passup_l(Sl,  error_msgs) ; 

) 

I  expression  LBRACK  expression  %prec 

( 

SS . xten_type_s  =  [REF_SYMBOL,  "(",  SI . xten_type_s, 

ACTUAL_DELIM,  S3.xten_type_sj; 

stbi_build2 (Si,  S3); 
passdn_stbl2 (SI,  S3); 

Ivisibility  information 

passdr.2_2  (SI,  Sj,  v.s*bie_types,  visibie_names)  ; 

.'error  messages 

SS .error_msgs_s  =  (SI ,error_msgs_s,  S3 .error_msgs_s] ; 

) 

1  '  ( '  expression  * )  ' 

< 

passup_l(S2,  xten_type); 

stbl_buildl (S2)  ; 
passdn_stbll (S2)  ; 

Ivisibility  information 

passdr._2(S2,  visible_types,  visible_names)  ; 

I error_mes sages 
passup_l(S2,  error_msgs) ; 

) 

' ('  expression  NAME  ')'  I  expression  with  units  of  measurement 

!  standard  time  units:  NANOSEC  MICROSEC  MILLISEC  SECONDS  MINUTES  HOURS  DAYS 

WEEKS 

[ 

passup_l(S2,  xten_type) ; 

stbl_buildl  (S2)  ,- 
passdn_stbll  (S2)  ; 

Ivisibility  information 

passdn_2(S2,  visible_types,  visible_names) ; 
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!  error_inessages 
passup_l(S2,  error_rr.sgs)  ; 

) 

TIME  !  The  current  local  time,  used  in  temporal  events 

{ 

SS . xtentypes  =  ":real"; 

stbl_buildO () ; 

lerror  messages 
$S .error_msgs_s 

) 

!  DELAY 

( 

SS . xten_type_s 

stbl_buiidC ( ) ; 

lerror  messages 
SS  . error_msgs_s  = 

} 

I  PERIOD  !  The  time  between  successive  events  of  this  type 

l 

SS  .  xter._type_s  -  ":real"; 

stbi_bu i ldO ( ) ; 

'error  messages 
SS .error_msgs_s  = 

> 

literal 

< 

passup_l(Sl,  xten_type) ; 

stbl_buildl (SI ) ; 
passdr,_stbll  (SI)  ; 


!  The  time  between  the  triggering  event  and  the  response 
=  " : real" ; 


'visibility  information 

pas sdr._2  ( S 1 ,  visible_types,  visible_names) ; 

1 error_mes sages 
passup_l(Sl,  error_msgs); 

literal  actual_name  !  literal  with  explicit  type 

!***  unsjre  about  this  one. 
passup_i(Sl,  xten_type); 

stbl_build2  (SI,  S3)  ,- 
passdn_stb!2 (S 1 ,  S3); 

'visibility  information 

passon2_2 (SI ,  S3,  vi s ibie_t ypes ,  visible_names) ; 

.'error  messages 

S S  .  e r rcr_msgs_s  =  i  S 1  .  er  ror_rr.sgs_s ,  S3  .error_msgs_s;  ; 

Ar.  ur.oefined  value  tc  be  specified  later 
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S S . xten_type_s  * 
stbl  buildO ( ) ; 


) 

•  j ' 

( 


terror  messages 
SS . error_msgs_s  = 

!  An  undefined  and  illegal  value 


SS . xten_type_s  ■= 

stbl_buildO () ; 

terror  messages 
$$ .error_msgs_s  = 

} 

IF  expression  THEN  expression  middle_cases  ELSE  expression  FI 

< 

SS . xten_type_s  =  $4 .xten_type_s; 


stbl_build4 (S2,  $4,  S5,  $7) ; 
passdn_stbl4  (S2,  S4,  $5,  $7); 


tvisibility  information 

passdn4_2 (S2,  $4,  $5,  $7,  visible_types,  visible_names) ; 


terror  messages 

SS ,error_msgs_s  =  [S2 .error_msgs_s,  $4 .error_msgs  s, 
$5 .error_msgs_s,  $7 .  error_msgs>_s j ; 


middle__cases 

:  middle_cases  ELSE  IF  expression  THEN  expression 

( 

Stbl_build3  (SI,  S3,  $5)  ; 
passdn_stbl3  (SI,  S3,  S 5 ) ; 

tvisibility  information 

passdn3_2 ( S 1 ,  S3,  SS,  visible_types,  visible_names) ; 
terror  messages 

-error_msgs_s  -  (SI .error_msgs_s,  S3 ,error_msgs  s,  S5 .error_msgs_s] ; 

> 

( 

stbl_bui ldO ( ) ; 

terror  messages 
SS ,error_msgs  s  = 

} 


quant i f ier 

:  ALL 

;  SOME 
•  '/ 

NLMEEP 
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<  } 

I  SUM 

{  i 

I  PRODUCT 

{  > 

I  SET 

(  ) 

I  MAXIMUM 

(  ) 

I  MINIMUM 

(  ) 

!  UNION 

{  > 

!  INTERSECTION 

(  ) 


restriction 

:  SUCH  expression 

{ 

stbl_buildl ($2) ; 

!visibiiity  information 

passdr._2($2,  visible_types ,  visible_names) ; 

!  error_messages 
passop_l (S2 ,  error_msgs) ; 

) 

I 

stbl_buildC (' ; 

!error  messages 
SS. error  msgs_s  = 


literal 

:  INTEGER_LITERAL 

f 

SS  . xter._type_s  =  integer"; 

stbi_bui ldC ( ) ; 

.’error  messages 
SS  .error_msgs_s  - 

REA1_LITERAL 

SS . xten_type_s  =  ":real"; 
stbl_buildO  ()  ; 

terror  messages 
SS  .errcr_msgs  s  =  ""; 

1 

char_l:terat 

SS  .xter._type_s  =  ":char"; 

stbi  bui ldC O ; 
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terror  messages 
SS  .error_msgs_s  = 

) 

I  STRING_LITERAL 

< 

SS .xten_type_s  -  ":string"; 

stbl_buildO ( )  ; 

terror  messages 
SS  .error_msgs_s  * 

) 

I  NAME  t  enumeration  type  literal 

< 

SS . xten_type_s  *  " :enumerat ion"; 

stbl_buildO () ; 

terror  messages 
SS -error_msgs_s  = 

) 

I  LBSACK  expressions  !  sequence  literal 

SS . xten_type_s  =  sequence {", S2 . xten_type_s, 

stbl_buildl (52) ; 
passan_stbll (S2) ; 

tvisibility  information 

passar._2  (S2,  visible_types,  vi s ible_names /  ; 

!  error_messages 
passup_l (S2,  error_msgs) ; 

) 

t  ' ( '  expressions  ' ) ' 

{ 

SS  . xter._type_s 

stbl_buildi (S2) ; 
passdn_stbl 1 ( S2 ) ; 

tvisibility  information 

passdn_2 (S2,  visible_types,  visible_names) ; 

!error_messages 
passup_l(S2,  errcr_msgs); 

! 

I  expressions  expression  !  map  literal 

/ 

SS . xten_type_s  =  ["map{",  S2 .xten_type_s,  ACTUAL_DELIM, 

S4 . xten_type_s,  ")■]; 


!  set  literal 

=  ("-set!”,  S2.xten  type  s, 


stbl_build2  (S2,  S4>; 
passdr._stbl2  (S2,  S4); 


tvisibility  information 

pa  s  sar.  2_2  (  S  2 ,  St,  v i s icle_t ypes ,  visible  names); 


! error  messages 

$$. error  m.sgs_s  =  [  S2  .  er  ror_msgs_s,  $4. error  rr.sgs  s ;  ; 

L3RACK  pairlist  !  tuple  literal 

i 

$S  .  xier.  type  s  =  [  "tuple i",  $2  .  xten_t ype_s ,  "}"]; 

stbl_buildl  ($2) ; 
passdn_stbll ($2) ; 

Ivisibility  information 

passdn_2<$2,  visible_types,  visible_names) ; 

! errcr_mes sages 
passup_l($2,  error_msgs); 

} 

' {*  pair  !  one_of  literal 

{ 

$$  .  xt  er._t  ype_s  =  $2.type_s; 

stbl_bui Idl  ( S 2)  ; 
passdn_stbl 1  ($2) ; 

ivisibility  information 

passdn_2  (  $2,  vi  sifc*e_types,  visibie_nam.es)  ; 

! er ror_mes sages 
passup_l  ($2,  er rcr_m.sgs )  ; 


relatic r  literals  are  sets  of  tuples 


expressions 

:  ^xc ress.cn  list 

p a s s u p_ 1  (SI,  x t e n  t ype )  ; 

s  t c . _  fc u : Idl  ( $  1 )  ; 
passer  *tsl 1  (SI ) ; 

'visic.lity  in  format  icr. 

pass2n_2(S.r  v:siD.e_ types,  visible_ names); 

’  e  r  r  c  r  _  me  s  s  a  ge  s 
pass  up  -  (SI,  error _rsgs); 


<  e 


x  t  e  r. 


;pej  = 


s  ‘  r:  .  r  —  -3 «  C  J  ; 

error  me  s  s  a ip s 
3  G  .  e  r  r  :  -  s  g  s  s  - 
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pair_list  ' , '  pair 

( 

S S . xten_t ype_s  =  [  $  1 .  xter._t ype_s ,  PAIR_D£LIM,  S3 . xten_t ype_s ] ; 

stbl_build2 (SI,  S3)  ; 
passdn_stb!2 (SI,  S3) ; 

(visibility  information 

pa^sdn2_2 (SI,  $3,  visible_types,  visible_names) ; 
ierror  messages 

SS .error_msgs_s  ■=  (SI  .error_msgs_s,  S3 ,error_msgs_s] ; 

} 

NAME  pair 

( 

SS .xten_type_s  =  [Sl.ttext,  S2.type_s,  PAIR_DELIM,  S2 . xten_t ype_s ] 

stbl_buildl (S2)  ; 
passdn_stbll ($2 )  ; 

(visibility  information 

passdn_2(S2,  visible_types,  visible_names) ; 

! error_messages 
passup_l(S2,  error_msgs); 

i 

pair 


passup_l($l,  xtentype) ; 

stbl_buildl (SI)  ; 
passdn_stbll  (SI)  ; 

'visibility  information 

passdr._2  (SI,  visibie_types,  visible_names)  ; 

: error_messages 
passup_l(Si,  error_msgs); 


NAME  BIND  expression 

! 

SS .xter_type_s  =  [Si.itext,  S3  .  xter._type_s  J  ; 

SS.types  -  S 3 . xten_t ype_s; 

stbl_buildl (  i 3 ) ; 
passd.n_stbll  (S3)  ; 

!visibiiity  ir.formatirr. 

passdn_2(S3,  vi s ible_types ,  visibie_names) ; 

! errcr_mes sages 
passop_l(S3,  error_msgs) ; 
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operator_I ist 

:  cperatcr_list  opera'  or_symboi 

i 

passan_3($l,  xref_vaiue,  message_f args,  ip_mcmxref) ; 
passdn_stbi  1  ($1)  ; 

$$  . d_error__s  =  check_compiex_decl ($$ . ip_mcmxref_i ,  $2  .  operat cr_text_s , 
$$ .message_fargs_i,  $2.1ine_s,  SS . stbl_names_i ) ; 
'modified  version  of  #mk_complex_decl 
$$ . ip_mcmxrer_s  ®  (SS  . d_error_s  •«  NU^L_STRING) 

->  ($1 .  ip__mcmxref_s  ($2  . operator_text_s)  ■*  NULL_STRING) 

->  { ($2.operator_text_s  :  ( $  $ .message_fargs_i , 

XREFJDELIMITER,  i2s <SS . xref_value_i ) ) ) }  *1 
S 1 . ip_mcmxref_s 

* # '  {  { $2  .  operator_text_s  :  ( $1 .  ip_mcmxref_s 

($2 . operator_text_s) , 
PATTERN_DELIMITER,  SS .message_fargs_i , 

XR£F_DELIKITER,  i2s ( $$ . xref_value_i ) ] ) )  +1 
S 1 . ip_mcmxre  f_s 
$1 . ip_mcmxref_s; 

! error  messages 

SS  . er ror_msgs_s  *  [  $1  .e  ror__msgs_s,  $$  . d_error_s ]  ; 


operatcr_symbol 

SS .errcr_msgs_s  =  check_complex_decl ($$ . ip_mcmxref_i,  $1 . operator_text_s, 
$$ .message_f args_i,  $l.line_s,  SS . stbl_names_i ) ; 
mk_co.Tpiex_de- I  ($5  .  ip_mcmxref ,  $$  .er ror_msgs_s,  $1 . operatcr_text_s , 

$$ . xref_vaLue_i,  $$ .messagef args_i ) ; 


ope  rat  or_syrrbc  I 
:  NOT 

SS  .  operat crtexts  *  Sl.%text; 
SS.lir.e  s  »  S  1  .  %  1 :  r.e ; 


SS . operate r_text_s  =  Sl.%text; 
SS  .  1  ir.e  s  =  SI .  %  lire; 


SS .cpe rater _text_s  =  $l.%text; 
SS.line  s  =  SI. I line; 


SS .cperatcr_text_s  =  $l.%text, 
S3,  lire  s  =  Sl.%lir.e; 


SS.cpe:a:::_:ex:_s  =  Sl.ltext; 
$$..;re  s  =  $  1.11  me; 
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{ 

SS .operator_text_s  =  "< 
SS.iine_s  =  $i.%line; 

) 

i  GT 

( 

SS . operator_text_s  *  "> 
S S . 1 ine_s  -  Sl.lline; 

) 

I  EQUALS 

( 

SS . operator_text_s  *  "• 
SS.line_s  =  $1.41ine; 

} 

I  LE 

{ 

SS .operator_text_s  *  SI 
SS.line_s  =  S1.41ine; 

) 

GE 

S S . opera tor_text_s  =  SI 
SS.line_s  *  S1.41ine; 

i  NE 

SS . operator_text_s  =  SI 
SS.line_s  «  Sl.%line; 

; 

I  NET 

f 

SS  . 0perat0r_t.ext.__3  *  SI 
SS.Iine_s  =>  SI.  4  line; 

) 

I  NGT 

SS . ope:atcr_text_s  =  SI 
SS.line_s  =  S1.41ir.e; 

) 

NLE 

SS.operator_text._s  =  SI 
SS . 1 ine_s  =  SI. 4  line; 

i 

i  NGE 

SS ,operator_text_s  =  SI 
SS.line_s  =  S 1.4  line; 

) 

i  EQV 

< 

S S . operat or_text_s  -  SI 
S$.iine_s  =  S1.41ine; 

f 

i  N'EQV 

I 

S $ . ope ra t cr_text  s  «  SI 
SS.iir.e_s  =  Si.  4  line; 


.  4text; 


4text; 


4text ; 


.  4text ; 


4text ; 


.  Itext ; 


4texc; 


.  4text ; 


•4text; 
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PLUS MARK 

I 

S S . ope  rat or_text_s  =  "t"; 
SS.ime_s  =  SL.%iine; 

) 

t  MINTSMARK 

( 

SS . operator_text_s  = 

$S.line_s  -  $i.»line; 

) 

I  STARMARK 

( 

SS .operator_text_s  - 
SS.line_s  =  Sl.%line; 

) 

I  SLASH 

{ 

SS . operator_text_s  = 

SS.line_s  =  Sl.tline; 

) 

:  MOD 

SS . operator_text_s  =  Sl.ttext; 
SS.line_s  =  Sl.tiine; 

1 

EXP 

( 

SS . operatcr_text_s  =  Sl.%text; 
SS.line_s  =  Si.%line; 


SS . operator_text_s  =  Sl.ltext; 
SS.irr.e_s  =  Sl.%lir.e; 

) 

APPEND 

f 

SS . ope rator_text_s  =  Sl.%text; 
SS.line_s  =  Sl.%line; 
l 

IN 


S  S . ope  rat  o 
SS  .  1  rr.e_s 

i 

RANGE 

SS . operator_text_s  =  Sl.ttext; 
SS . 1 ine_s  =  Sl.tiine; 

) 

DOT MARK 

( 

SS . operator_text_s  = 

SS  .  1  ir.e_s  »  Sl.tiine; 

L3RACK 


r_text_s  =  Sl.ttext; 
=  Sl.tiine; 


SS. ope  rater _text_s  = 
SS  .  .ir.e  s  =  S 1 .  %  1 1 ne ; 
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APPENDIX  C  -  SYNTACTIC  ERROR  PRODUCTIONS 


This  Appendix  contains  the  syntactic  error  productions  that  were  developed  for 
version  1.5  of  the  SPEC  grammar.  This  version  was  five  versions  prior  to  the  version 


used  for  the  type  checker,  but  the  methodology  used  to  implement  the  error  productions 
is  fully  applicable  to  the  newest  version  of  the  grammar.  For  the  type  checker  to  be  a 
fully  functional  tool,  these  error  productions  must  be  integrated  into  the  anal  product.  In 


this  way,  syntactic  and  semantic  errors  could  be  identified  concurrently. 

version  stamp  SHeader:  spec.k,v  1.5  88/02/16  13:27:58  berzins  Exp  S 
!  In  the  grammar,  comments  go  from  a  to  the  end  of  the  line. 

'  Terminal  symbols  are  entirely  upper  case  or  enclosed  in  single  quotes  (')- 
!  Nonterminal  symbols  are  entirely  lower  case. 

1  Lexical  character  classes  start  with  a  captial  letter  and  are  enclosed  in  {}. 
1  In  a  regular  expression,  x+  means  one  or  more  x's. 

’  In  a  regular  expression,  x*  means  zero  or  more  x's. 

!  In  a  regular  expression,  (xyz)  means  x  or  y  or  z. 

!  In  a  regular  expression,  [Axyz]  means  any  character  except  x  or  y  or  z. 

!  In  a  .egular  expression,  [a-z]  means  any  character  between  a  and  z. 

!  In.  a  regular  expression,  .  means  any  character  except  newline. 


!  definitions  of 

%define  Digit 

%defir.e  Ir.t 

% define  Lette 

%aefine  Alpha 

laefir.e  Blank 

%aefine  Quote 
%aefine  Bacxslash 
%aefme  Cr.ar 

!  ae fin  it  ions  of 


lexical  classes 


: ( ;a"\\] 


white  space  and 


:  [0-9] 

: {Digit }  + 

: i a-zA-Z ] 

: ({Letter) ] {Digit! I 
: [  \t\n) 

:  !"] 

: " \  \" 

i  {Backslash) {Quote )  (Backslash) (Backslash ) ) 
comments 


'■  definitions  of  compound  symbols  and  keywords 


AND 

CR 


M?  LIES 


: {Blank ) + 

. «"\n” 


n  £  h 
.  |  n 


h  _.  >  n 


"<  =  >" 


"<  = 
">  = 
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NLE 


NGE 

EQV 


NEOV 


"-<  =  * 


n_  =  n 


RANGE 

APPEND 

MOD 

EXP 


•I  fl 

"  |  j  " 

(Backslash ) I  MOD 


BIND 

ARROW 


IF 

THEN 

ELSE 

IN 

'J 


IF 

THEN 

ELSE 

IN 

U 


ALL 

SOME 

NUMBER 

SUM 

PRODUCT 

SET 

MAXIMUM 

MINIMUM 

UNION- 

INTERSECTION 

SUCH 

ELSE  IF 


:  ALL 
••SOME 
: NUMBER 
:  SUM 

: PRODUCT 
:  SET 

: MAXIMUM 
: MINIMUM 
: UN  ION 

: INTERSECTION 
:SUCH(Blank) ’THAT 
:ELSE ( Blank ) *  IF 


AS 

CHOOSE 

CONCEPT 

DEFINITION 

DELAY 

DC 

END 

EXCEPTION- 

EXPORT 

FOREACK 

FROM 

FUNCTION 

GENERATE 

HIDE 

IMPORT 

INHERIT 

INITIALLY 

INSTANCE 

INVARIANT 

ITERATOR 

MACHINE 

MESSAGE 

MODEL 

OD 

OPERATOR 

OTHERWISE 

PERIOD 


:  AS 

: CHOOSE 
: CONCEPT 
: DEFINITION 
: DELAY 
:  DO 
:  END 

:  EXCEPTION 
: EXPORT 
:FI 

:FOREACH 
:  FROM 
: FUNCTION 
:  GENERATE 
:  HIDE 
:  IMPORT 
: INHERIT 
: INITIALLY 
: INSTANCE 
: INVARIANT 
: ITERATOR 
: MACHINE 
: MESSAGE 
: MODEL 
:  OD 
:  OF 

: OPERATOR 
: OTHERWISE 

:PERIO"' 
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RENAME 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION 

TRANSITION- 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 


.-RENAME 
:  REPLY 
:  SEND 
: STATE 
: TEMPORAL 
:  TIME 
:  TO 

: TRANSACT ION 
:  TRANS  IT  ION 
:  TYPE 
.-VALUE 
: VIRTUAL 
:WHEN 
: WHERE 


SECONDS 

MINUTES 

HOURS 

DAYS 

WEEKS 

NANOSEC 

MICROSEC 

MILLISEC 


:  SECONDS 
:MINUTES 
:  HOURS 
:DAYS 
: WEEKS 
:  NANOSEC 
: MICROSEC 
tMILLISEC 


INTEGER_LITERAL 
R£AL_LITERAL 
CHAR_LITERAL 
STRING  LITERAL 


: { Int } 

Mint)"."  (Int) 

.  n  t  n  n  t  »» 

: (Quote } (Char ) * (Quote } 


NAME 


:  ( Letter } (Alpha ) * 


!  operator  precedences 
!  %left  means  2+3*4  is  (2+31+4. 


♦  left 
%  lef  t 
%  ie  ft 
%  lef  t 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 
♦nonassoc 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 

♦  left 


IF,  DO,  EXCEPTION,  NAME,  SEMI ; 

’ , ' ,  COMMA; 

SUCH; 

IFF; 

IMPLIES; 

OR; 

AND; 

NOT; 

•>',  LE,  GE,  NE,  NLT,  NGT,  NLE,  NGE,  EQV,  NEQV 

IN,  RANGE; 

U,  APPEND; 

'+',  PLUS,  MINUS; 

'/’,  MUL,  DIV,  MOD; 

UMINUS; 

EXP; 

'  S'  ,  '(’,  '(',  DOT,  WHERE; 

STAR; 


%♦ 

lattribute  declarations 

♦  ♦ 

!  productions  of  the  grammar 


s 


art 


spec 
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i 


spec 

:  spec  module 

{ 

} 

i 

( 

) 

I  spec  error  module 

{ 

) 


!  A  production  with  nothing  after  the  "I"  means  the  empty  string 
!  is  a  legal  replacement  for  the  left  hand  side. 

module 

:  function 
i 
} 

'  machine 

( 

} 

!  -ype 

< 

) 

I  definition 
l 
» 

!  instance  !  of  a  generic  module 

{ 


:  opt iona 1 ly_vi rtua 1  F 'NOTION  interface  messages  concepts  END 

} 

l  opt  ior.al  ly_vi  rtua  i  FUNCTION  error  messages  concepts  END 


} 

1  opt i era  1 ly_vi rtua 1  FUNCTION  interface  error 


'  Virtual  modules  are  for  inheritance  only,  never  used  directly. 

machine 

:  opt iona 1 ly_virtua 1  MACHINE  interface  state  messages  transactions  temporals 

concepts  END 

1  opt iona 1 i y_vi rtua 1  MACHINE  error  state  messages  transactions  temporals  concepts 

END 


opt iona lly_ virtual  MACHINE  interface  error 
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type 


:  optionaily_virtual  TYPE  interface  model  messages  transactions  temporals 


concepts  END 

{ 

} 

I  optionally_virtual  TYPE  error  model  messages  transactions  temporals  concepts  END 

( 

) 

I  optionally_virtual  TYPE  interface  error 

( 

} 


definition 

:  DEFINITION  interface  concepts  END 

<  i 

I  DEFINITION  error  concepts  END 


1  DEFINITION  interface  error 

) 


instance 

:  optionally_virtual  INSTANCE  parametr ized_name  parametrized  name  hide 

renames  END 

f 

:  optionally_virtuai  INSTANCE  error  parametrized_name  hide  renames  END 

( 

1 

opt  icr.a i  1  y_vi rtua  I  INSTANCE  pa ramet  r  i zed_name  error  END 

! 


opt i ora  1 1 y_vi rtua 1  INSTANCE  parametrized_name  error  END 


) 

opt tona 1 1 y_vi rtua 1  INSTANCE  parametrized_name  parametrized_name  error 


For  making  instances  or  partial  instantiations  of  generic  modules, 
!  and  for  making  interface  adjustments  to  reusable  components 
■  by  hiding  or  changing  some  names. 
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renames  RENAME  NAME  AS  error 

< 


imports 


export 


messages 


message 


!  Renaming  is  useful  for  preventing  name  conflicts  when  inheriting 
!  from  multiple  sources,  and  for  adapting  modules  for  new  uses. 

!  The  parameters,  model  and  state  components,  messages,  exceptions, 
!  and  concepts  of  an  actor  can  be  renamed. 


:  imports  IMPORT  name_list  FROM  parametr ized_name 


I  imports  IMPORT  error  FROM  parametrized  name 


) 

imports  IMPORT  name_list  error  parametrized_name 

< 


} 


imports  IMPORT  name_list  FROM  error 

( 


:  EXPORT  name  list 


} 

EXPORT  error 


t 


:  messages  message 


:  MESSAGE  message_header  operator  response 


MESSAGE  message  header  error 


respcr.se 

:  response__body 

{ 

} 

I  response_cases 

{ 

} 


responsecases 

:  WHEN  expression^list  response_body  response_cases 

{ 

} 

I  OTHERWISE  response_body 

} 

I  WHEN  error  response_body  response_cases 

{ 

} 

I  WHEN  expression_list  response_body  error 

{ 

} 

OTHERWISE  error 

; 

v 


response_body 

:  cpt_chocse  opt_reply  opt_sencs  opt_t  r ans i t ion 

{  ) 

cpt_choose 

:  CHOOSE  '  ('  fieia_list  restriction  ')' 

} 

{  } 

CHOOSE  error  field  list  restriction 


i  CHOOSE  ' ('  error  ')' 

CHOOSE  ' ('  field_list  restriction  error 

i 


opt_repl y 

:  REPLY  message_neader  where 

( 

GENERATr  ressace  header  where  !  used  in  ite 


181 


s 


opt_sends 

:  sends 

{  ) 

! 

<  ) 


sends 

:  sends  send 

< 

) 

i  send 

{ 


send 

:  SEND  message_header  TO  paramet rized_name 

} 

l  SEND  message_header  error  parametrized_name 

{ 

} 

SEND  nessage_heade r  TC  error 

{ 


cpt_transit ion 

:  transition. 

<  ) 


t  ransit ion 


:  TRANSITION  expres s ior._i ist 


TRANSITION  error 

{ 


message_'neader 

:  opt iona 1  except  ion  optional  rare  formal 


:  express. c' 


where  foreach 


where  foreach 


for  describing  state  changes 


a  rgument  s 
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t 

f 


%prec  SEMI 


WHERE  error 

( 

1 


!  most  have  a  iower  precedence  than  WHERE 


opt iona!ly_virtuai 

:  VIRTUAL 

( 

) 

I 

( 

) 


optionaI_exceptior, 

:  EXCEPTION 

( 

) 

[  %prec  SEMI 


) 


operator 

:  operator  OPERATOR  operator_list 

! 

i 

I 

( 

} 

operator  OPERATOR  error 
( 


f creach 

:  FCREACH  ' ('  field  list  restriction  ’)' 


( 

) 

FOREACH  error 

f 


FCREACH  '  r  error 
l 


FOREACH  is  used  to  describe  a  set  of  messages  to  be  sent. 


183 


concept  s 

:  concepts  concept 

( 

) 

( 

) 


concept 


:  CONCEPT  NAME  formal_parameters  type_spec  where 

!  constants 


where 


where 


) 

I  CONCEPT  NAME  formal_parameters  formaI_arguments  where  VALUE 
!  functions 

{ 

) 

I  CONCEPT  error  forma l_p i-aset »r?  formal  a rg1 ’•««•••►_  •  vhe.e  VALUE  i_. 

{ 


I  CONCEPT  NAME  error  VALUE  formal_arguments  where 

( 

) 

:  CONCEPT  NAME  error  type_spec  where 

( 

) 

I  CONCEPT  NAME  forma l_parameters  error 

{ 

) 

I  CONCEPT  NAME  formal_parameters  formal_arguments  where  VALUE  erro 

} 


model  !  data  types  have  ccnceptual  models  for  values 

:  MODEL  f ormal_arguments  invariant 

; 

) 

l  MODEL  forma l_argumer.ts  invariant  initially 

!  initially  clause  specifies  automatic  variable  initializati 

i 

) 

I  MODEL  error  invariant  initially 

I  MODEL  formal_arguments  invariant  error 

{ 

) 


state  !  machines  have  conceptual  models  for  states 

:  STATE  forma l_arguments  invariant  initially 

( 

} 

i  STATE  error  invariant  initially 

;  ) 

1  STATE  form.al_argunents  invariant  error 

( 
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invariant  !  invariants  are  true  in  ail  states 
:  INVARIANT  expressior._iist 

( 

) 

i  INVARIANT  error 

{ 

} 


initially  !  initial  conditions  are  true  only  at  the  beginning 
:  INITIALLY  expression_list 

{ 

) 

I  INITIALLY  error 

{ 

) 


transactions 

:  transactions  transaction 

{ 

> 

I 

f 


transaction 

:  TRANSACTION  paran.et r i zed_r.ame  act i on_expression  where 

( 

; 

1  TRANSACTION  error  action  expression  where 

< 

; 

TRANSACTION  pa rarnet r i zed_nane  error 

< 

) 

I  TRANSACTION  paramet r i zed_name  error 

{ 

l 

!  Transactions  are  atonic. 

•  T.-.e  where  clause  can  specify  timing  constraints, 
act  ior,_express  i  cn 

:  action_expression  action_list  %prec  SEMI  !  sequence 

( 

i 

action_iist 

f 

i 

i  act icn_expression  error 

t 


act i on_l i s t 

:  action_list  actior._list  tprec  STAR  !  parallel 
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i  IF  alternatives  FI  choice 


DO  alternatives  OD  !  repetition 


I  paramet rized_name  !  a  normal  message 


I  EXCEPTION  parametrized_name  !  an  exception  message 


IF  error  FI 


} 

DO  error  OD 

{ 

} 

EXCEPTION  error 

( 


IF  alternatives  error 

{ 

) 

DO  alternatives  error 

< 


alternat ives 

:  alternatives  OR  guard  action  expression 

i 

I  guard  action_expression 

{ 

) 

I  alternatives  OR  error 

< 

) 


guard 

:  WHEN  expression  ARROW 

{ 

> 

( 

) 

I  WHFN  error  ARROW 

( 

) 

I  WHEN  expression  error 

< 

I 

temporal s 

:  temporals  temporal 

f 
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I 


) 


temporal 

:  TEMPORAL  NAME  where  response 

( 

) 

I  TEMPORAL  error 

( 

) 

I  TEMPORAL  NAME  error 

i 

) 

!  Temporal  events  are  trigged  at  absolute  times, 

!  in  terms  of  the  locai  clock  of  the  actor. 

!  The  "where"  describes  the  triggering  conditions 
!  in  terms  of  "TIME"  and  "PERIOD". 

formai_parameters  !  parameter  values  are  determined  at  specification  time 
:  fieid_list  '}'  where 

( 

) 

( 

I  ' ( '  error  ' } ’  where 
t 

} 

'!'  fielc_iist  error  where 

< 

) 

formal_arguments  :  arguments  are  evaluated  at  run-time 
:  '  ('  f ieid_iist  '  !  ' 

i 


'  ( '  error  '  )  ' 


'  ('  field_ltst  error 
l 


fiela_Iist 

:  field  list  ' , '  field 


field 


f.ela  list  error 
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I  error  field 

f 

) 


field 

( 

name_list  type_spec 

) 

1 

( 

'S'  NAME  ':'  type_spec 

} 

i 

1 

t 

'  ?' 

I 

J 

name_l ist  error 

< 

1 

1 

'S' 

{ 

error  type_spec 

1 

) 

'S' 

( 

NAME  error  type_spec 

1 

i 

'S' 

( 

NAME  ' : '  error 

1 

) 

name_list  error  type_spec 
{  )  ~ 

typespec 

< 

parametrized_name 

) 

1 

{ 

TYPE  actual  parameters 

) 

1 

1 

FUNCTION  actual_parameters 

1 

1 

MACHINE  actual  parameters 

I 

ITERATOR  actual_parameters 

1 

( 

) 

'  ? ' 

name  list 

i 

name_list  NAME 

) 

NAME 

i 


) 


name  of  a  data  type 
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opt:  tor.a  l_.name 

:  NAME  formal ^parameters 

{ 

i 

l 

i 

) 


parametr ized_name 

:  NAME  actual_parameters 

( 

) 


actual_parameters  !  parameter  values  are  determined  at  specification  time 
:  ' arg_list  ' )' 

( 

) 

I  Spree  SEMI  !  mus“  have  a  lower  precedence  than 

) 

1  '  {'  error  '  )' 

! 

i  ' { ’  arg_list  error 

{  i 


actual_argumer.ts  !  arguments  are  evaluated  at  run-time 
:  '  ('  arg_iist  '  )  ' 

( 

) 

r  Spree  SEMI  must  have  a  lower  precedence  than  '  (' 

{ 

} 

'  ('  error  '  )  ' 


' ( '  arg_list  error 

i  ; 


arg_list 

:  arg_list  arg  Spree  COMMA 

I 

) 

I  arg 

( 

! 

I  arg_list  ' , '  error 
f 
) 


arg 

:  expression 

( 

! 

pair 


189 


) 


expression_iist 

:  express ion_I i st  expression 


Iprec  COMMA 


I  expression 


expression_list  error 


error  ,  expression 

<  ) 


expression 


:  quantifier  ' ('  field_list  restriction  BIND  expression  ')' 


paramet  r ized_name  actua l_argument  s 


parametrized_name  '8'  parametrized_name  actual_argument s 


I  NOT  expression 


%prec  NOT 


expression  AND  expression 


%prec  AND 


:  expression  OR  expression 


%prec  OR 


expression  IMPLIES  expression 


%prec  IMPLIES 


expression  IFF  expression 


%prec  IFF 


expression  '<  expression 


%prec  LE 


1  expression  '>'  expression 


%prec  LE 


expression  expression 


tprec  LE 


expression  LE  expression 


tprec  LE 
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expression  GE 


expression 


Iprec  LE 


expression  NE 


expression 


%prec  LE 


I  expression  NLT  expression 


%prec  LE 


I  expression  NGT  expression 


%prec  LE 


I  expression  NLE  expression 


%prec  LE 


expression  NGE  expression 


%pree  LE 


I  expression  EQV  expression 


Iprec  LE 


i  expression  NEGV  expression 


%prec  LE 


' - '  expression 


%prec  UMINUS 


expression  expression 


»prec  PLUS 


expression  expression 


tprec  MINUS 


expression.  expression 


%prec  MUL 


i  expression  '/'  expression 


%prec  DIV 


expression  MOD  expression 


Iprec  MOD 


i  expression.  EXP  expression. 


%prec  EXP 


expression  U  expression 


%preo  U 
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expression  APPEND  expression 


tprec  APPEND 


l  expression  IN  expression 


tprec  IN 


expression  %prec  STAR 

■  ’x  is  the  value  of  x  before  a  transition 
!  x  is  the  value  after  the  transition 


I  'S'  expression  tprec  DOT 

•  Sx  represents  a  collection  of  items  rather  than  just  one 
si  =  ix,  Ss2)  means  si  »  union(fx),  s2) 

!  si  <=  [x,  Ss2J  means  si  -  append(tx),  s2) 


expression  RANGE  expression  tprec  RANGE 

x  in  [a  ..  b]  iff  x  in  •  a  ..  b!  iff  a  <=  x  <-  b 
•  [a  ..  b]  is  sorted  in  increasing  order 


\  expression  '.'  NAME 


expression  '  expression  '  '  ’ 


tprec  DOT 

tprec  DOT 


’  ('  expression  '  )  ' 


'('  expression  units  ')' 


timing  expression 


T IME 


•  The  current  local  time,  used  in  tempora'  events 


-~AY  :  The  time  between  the  triggering  event  and  the  response 


I  PERIOD  !  The  time  between  succ>  ssive  events  of  this  type 


literal 

litera*  f@'  paramet r i zed_name  !  literal  with  explicit  type 

!  An  undefined  va^ue  to  be  specified  later 
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Ar.  undefined  and  illegal  value 


IF  expression  THEN  expression  rr iddle_cases  ELSE  expressio 

I  expression  '>'  error 

{  } 

!  error  ' <'  expression 

{  ) 

'  quantifier  '  ('  error  ')' 

t 

} 

quantifier  error 

1  quantifier  ' ('  field_list  restriction  BIND  error  ')' 

i 

paranet  r  ized_r.ame  '  @ '  error 

NOT  error 

i 

error 

} 

' * '  error 

' S '  error 

; 

'  ('  error  ' ) ' 

IF  error  THEN  expression  r. i ad le_ cases  ELSE  expression  FI 
IF  expression  THEN  error  r.iddle_ca ses  ELSE  expression  FI 
IF  expression  THEN  expression  rriddie_cases  ELSE  error 

literal  ' @ '  error 

'  ('  expression  units  error 

/ 

j 

ecases 

:  r:ccle_cases  ELSE_IF  expression  THEN  expression 


rr.iadie_cases  ELSE_IF  expression  THEN  er 


quantifier 

:  ALL 


) 

:  SOME 

{ 

) 

I  NUMBER 

{ 

) 

I  SUM 


i  PRODUCT 


!  SET 


l 


maximum 


) 


MINIMUM 


‘  UNION 

; 


intersection 

I 


restrict ior 


{ 

) 


SUCH  expression 


\ 


e 


ro: 


or 
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literal 

:  INTEGER  LITERAL 


REAL  LITERAL 


) 

I  CHAR_LLTERAL 

( 


-  STRING_LITERAL 

< 


NAME 


enumeration  type  literal 


'  ' '  expressions  '  j ' 

'  • '  expressions  '  • ' 

) 

' expression  expressions  * }' 
i  ’ pair_list  ' ] ' 

' l '  pair  '  } ' 

' * '  error 

/ 

' ! '  error  ' ; ' 


t 


expression  error 

'  pair_List  error 
(  ) 

'  expres.- x  .  ,iSt  error 
l  ; 


!  secpience  literal 

!  set  literal 

!  map  literal 

!  tuple  literal 

!  one_of  literal 


expressions 


re.atio.  -  Jra,s  are  sets  of  tuples 
express  ior._l  ist 
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pair_list 


pair 


pair_list  ' ,  '  pair 


t  NAME  pair 


I  pair 


I 

I  pair_list  error 


:  NAME  BIND  expression 


NAME  BIND  error 


:  NANOSEC 


MICROSEC 


!  MILEISEC 


SECONDS 


I  MINUTES 


HOURS 


IAYS 


WEEKS 
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ope  r  a 


operat  or 


:  operator_list  operator_symbol 

) 

i  operator_syir,boI 

( 

) 

l  operaror_iist  error  operator_symboi 

( 

) 


symbol 
:  NOT 

( 


} 

i  ANO 

( 

'  OR 

i 

) 

IMPLIES 


'  <’ 


LE 


197 


199 


APPENDIX  D  -  TYPE  CHECKER  ATTRIBUTES. 


This  Appendix  contains  a  list  of  all  of  the  attribute  descriptive  names  used  in  the 
implementation  of  the  type  checker  with  their  purpose.  This  list  is  not  all  encompassing. 
Various  attributes  that  are  slight  variations  of  the  below  named  attributes  have  been  left 


out.  All  of  the  attributes  not  included  have  an  "ip"  prefix  with  a  "main"  name 
corresponding  to  a  name  listed  below. 


Attribute  Name 


%line 


A  Kodiyak  predefined  attribute  yielding  the  line  number 
in  the  source  text  of  a  terminal  symbol. 


%text 


A  Kodiyak  predefined  attribute  yielding  the  actual  text 
of  a  terminal  symbol. 


actual_name_text  The  actual  text  of  an  actual  name. 


actual_params 

actual_text__s 

arg_text 

arglist_text 

args_i 

d_error_s 

env_i 


The  actual  parameters  associated  with  an  actual  name. 

The  actual  text  associated  with  a  non-terminal. 

The  text  of  an  arg  non-terminal. 

The  text  of  an  argument  list  (argjist)  non-terminal. 

The  arguments  associated  with  a  particular  non¬ 
terminal.  This  attribute  is  commonly  used  in  the  formal 
name  non-terminal  to  obtain  the  arguments  associated 
with  the  name  so  a  "pattern"  may  be  created. 

An  attribute  containing  an  error  message  relating  to  the 
declaration  of  a  new  name  (if  any  such  error  exists). 

The  current  environment  of  a  non-terminal. 


error_msgs  This  attribute  contains  all  error  messages  identified  in 

the  current  and  children  non-terminals. 
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fieldpattem 


The  string  containing  the  non-terminals  name  and  it’s 
type,  separated  by  a  predefined  delimiter. 


global_type 

ip_lclzd_mcmxref 

ip_mcmxref 

ip_mxref 

local_types_s 

line 

message_name_s 

message.fargs.s 

mod_types 

module_name 

mxref.value 

name.fargs 

name_text 

name_type_text 

name_type_value 


A  map  containing  all  global  type  names  and  their 
translation. 

A  localized  attribute  containing  the  same  information  as 
the  mcmxref  attribute.  Used  in  the  final  stages  of  layer 
2  to  integrate  ip_mcmxref  attributes  from  different 
modules. 

A  map  containing  all  module,  message  and  concept 
names.  This  map  is  used  in  layer  2  to  build  the  layer  3 
attribute  "stbl".  The  range  of  the  map  contains  patterns. 

A  map  which  is  being  constructed  to  contain  all  module 
names.  The  range  of  the  map  contains  the  module 
names  pattern  and  cross  reference.  This  map  is  used  in 
layer  1  to  obtain  information  needed  in  the  layer  2  table 
"ip_mcmxref'. 

The  type  names  that  are  local  to  a  non-terminal. 

The  line  number  associated  with  a  non-terminal. 

The  text  of  a  message’s  name. 

The  text  of  the  formal  arguments  of  a  message. 

A  localized  map  containing  the  type  names  and  their 
translations  that  are  visible.  This  table  and  the 
"global_type"  attributes  are  used  to  build  the 
"visible. types"  map. 

The  name  of  the  current  module. 

The  cross  reference  value  of  the  current  module. 

The  formal  arguments  associated  with  a  name. 

The  text  associated  with  a  formal  or  actual  name. 

The  text  of  a  name’s  type. 

The  translated  value  (obtained  from  the  visible  types 
table)  of  a  name’s  type. 
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name_params 


operator_text 

signature 

stbl_class 

stbl_names 

stbl_params 

stbl_result 

text 

type_name_text 

type_name_value 

type_table_i 

visible_names 

visible_types 

xref_value 

xten_type_ 


The  parameters  associated  with  a  formal  or  actual  name. 

The  text  associated  with  an  operator  non-terminal. 

The  signature  (name  and  arguments)  of  a  non-terminal. 

Classes  of  all  names  used  (e.g.  Function,  Message,  etc.) 
Accessed  by  the  cross  reference  value  of  the  name. 

All  names  used  throughout  the  program.  Accessed  by  a 
cross  reference  value. 

The  formal  parameters  of  a  name  (if  any).  Accessed  by 
a  cross  reference  value. 

The  resultant  type  of  a  name.  Contains  extended  type 
information.  Accessed  by  the  cross  reference  value  of 
the  name. 

The  text  of  a  non-terminal. 

The  text  of  a  type_spec’s  name. 

The  translated  value  of  a  type_spec. 

A  map  coalescing  the  contents  of  the  ”mod_types”  and 
"global_type"  tables. 

A  map  containing  all  names  visible. 

A  map  containing  all  type  names  visible. 

The  cross  reference  value  of  the  current  name. 

The  extended  type  of  a  non-terminal. 
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